[
https://issues.jboss.org/browse/JGRP-2017?page=com.atlassian.jira.plugin....
]
Bela Ban edited comment on JGRP-2017 at 2/22/16 1:14 PM:
---------------------------------------------------------
OK, I'll take a look whether byte[] arrays can be reused, too.
Something to try out might be to replace the payload of the existing messages *in-place*
and add a {{CompressHeader}} if successful. We have to consider the following cases:
h5. {{COMPRESS}} is _above_ {{NAKACK2}} / {{UNICAST3}}
The message is added to {{NAKACK2}} / {{UNICAST3}} with a compressed payload and a
{{CompressHeader}} attached.
{{NAKACK2}} / {{UNICAST3}} will retransmit the _compressed_ message
h5. {{COMPRESS}} is _below_ {{NAKACK2}} / {{UNICAST3}}
{{NAKACK2}} / {{UNICAST3}} will retransmit the _compressed_ message (it was compressed by
{{COMPRESS}} on the first send).
{{COMPRESS}} will try to compress the message again. To prevent this, we could check if
the message has a {{CompressHeader}} and skip compression if so. However, small messages,
or messages which grew in size rather than shrunk, will not have a header, so perhaps we
need to add a {{CompressHeader}} in all instances and add a flag which tells {{COMPRESS}}
whether to uncompress or not.
was (Author: belaban):
OK, I'll take a look whether byte[] arrays can be reused, too.
Something to try out might be to replace the payload of the existing messages *in-place*
and add a {{CompressHeader}} if successful. We have to consider the following cases:
h5. {{COMPRESS}} is _above_ {{NAKACK2}} / {{UNICAST3}}
The message is added to {{NAKACK2}} with a compressed payload and a {{CompressHeader}}
attached.
NAKACK2 will retransmit the _compressed_ message
h5. {{COMPRESS}} is _below_ {{NAKACK2}} / {{UNICAST3}}
NAKACK2 will retransmit the _compressed_ message (it was compressed by COMPRESS on the
first send).
COMPRESS will try to compress the message again. To prevent this, we could check if the
message has a CompressHeader and skip compression if so. However, small messages, or
messages which grew in size rather than shrunk, will not have a header, so perhaps we need
to add a CompressHeader in all instances and add a flag which tells COMPRESS whether to
uncompress or not.
Optimize COMPRESS protocol by pooling / re-using byte array/buffer
------------------------------------------------------------------
Key: JGRP-2017
URL:
https://issues.jboss.org/browse/JGRP-2017
Project: JGroups
Issue Type: Enhancement
Affects Versions: 3.4.5, 3.6.7
Environment: Wildfly 8.2.1.Final (JGroups 3.4.5)
Reporter: Mathieu Lachance
Assignee: Bela Ban
Fix For: 3.6.8, 4.0
I'm currently working to minimize our application UDP bandwith usage by enabling the
COMPRESS protocol in Wildfly 8.2.1.Final.
Enabling the COMPRESS protocol works fine on that regards by reducing approximatly by 7x
the amount of UDP traffic which is really neat.
The thing is by enabling compression we are trading off increased cpu / memory usage for
lowered network bandwith usage. In our case, we actually a notable increase of the cpu /
memory usage due to increased usage of the garbage collector.
When I had a look at the COMPRESS protocol implementation we see that both Deflator and
Inflator are pooled and re-used (great) but not at the byte array level (not great).
This compression pattern is very similar to GZip compression filter we can find in any
recent Http spec implementors. In the Netty project for example, there's various
compression protocol and/or utilities that are available and fine-tunable and they all
have in common to re-use byte buffer and/or try to avoid byte arrays instantiation/copy at
maximum.
Here is some notable classes of the Netty implementation:
https://github.com/netty/netty/blob/4.1/codec-http/src/main/java/io/netty...
https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/hand...
https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/hand...
https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/hand...
I think re-implementing something similar in JGroups would yield great benefits to the
COMPRESS protocol. Maybe also, there's something that could be picked off right from
the JBoss XNIO and/or the Undertow projects?
Finally, I do not know also if we could add ergonomics at the same time to automatically
determine the best number of Deflator and Inflator by keeping trace of the amount of time
waited to pool one of them?
Thanks,
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)