[Bug 2048] HTTP transport should be compressed

[bugzilla-daemon at icedtea.classpath.org]

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2048

--- Comment #5 from Jon VanAlten <jon.vanalten at redhat.com> ---
(In reply to Severin Gehwolf from comment #2)
> The idea was to compress client *and* server side.

<SNIP>

> Why are you asking? Sure, it would mean more CPU cycles are
> spent for compression/deflation but this shouldn't be significant. If you
> are worried about extra overhead we could surely make this configurable.
> Though, it would be trading extra CPU cycles for less time being spent on
> sending traffic over the wire.

Can I suggest to do some measurement to determine whether we *want* to do such
a trade, before putting in the effort to implement it, or if implementation is
trivial then get some performance data and consider the impact before pushing a
change like this?  I'm not convinced by advice that almost all web apps will
benefit from a compression filter.  Without giving a bunch of links, most
similar advice is assuming a browser-facing web application.  Maybe I am taking
it a bit further by saying this, but I would say that this also assumes that
one of the primary purposes of the machine that the client is running on would
be to interface with such web apps, and let's be honest most machines on which
people are using a web browser have a lot of CPU cycles to spare.  In the case
of the Thermostat agent, the primary purpose is to run the workload we are
monitoring, and we try for this agent to be as minimal as possible in a way
that no-one would ever consider with a web browser.  So, maybe this general
advice to always use compression filter doesn't apply so cleanly to Thermostat.

I guess another thing to consider here is how much benefit we would even get
out of compression.  Just spit-balling here, and I am not intimately familiar
with compression algorithms, but my understanding is that the compression ratio
will have some relation to the presence of repeated patterns in the source data
(and the rest of what I say depends on this assumption).  The gui or cli
client, most of the time, is making requests that will return batches of data
(multiple documents from a collection).  I suspect we will see good compression
ratio for such requests; these documents will contain some amount of repeated
fields which the compression algorithm will benefit from.  The agent, most of
the time, is putting in a single document per request.  Smaller source
material, with likely less repetition -> less bandwidth gained for same CPU
cost.  Maybe it would be worth doing a quick check, apply compression to some
representative data, see how it looks?

Ultimately though, if we don't have evidence of network i/o as a bottleneck,
I'd put it in the "if it ain't broke, don't fix it" bucket.  I mean this mostly
for the agent; there's less concern about the trade-off in the web app or the
client, because they are isolated (assuming remote configuration) from the
system-under-observation.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141027/3cc7aab5/attachment.html>