On Wed, May 16, 2012 at 12:12 PM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> I do. Look at the numbers in the issue. I compare neon and serf with
> mod-deflate. I compare neon and serf without mod-deflate. I compare
> neon and serf over https.
I maintain that's still not a fair comparison - but, let me elaborate
on that point as it goes into why I think we should move away from
ra_neon. In my mind, the overall goal of any RA layer should be to
leverage the network as efficiently as possible - but, ra_neon makes
it far harder to do that as everything is far too tightly coupled.
ra_serf is intentionally designed to work with other parts of httpd -
that leads to the avoidance of creating a custom fulltext compression
scheme. Obviously, when going against a known fulltext to both sides,
svndiff makes a lot of sense; and ra_serf/mod_dav_svn (and ra_neon
too) will still happily use that when the client indicates it has a
prior version. The test case in the issue is about the fresh checkout
case where there is no mutually known fulltext - here, svndiff isn't
as useful and actually hurts ra_neon quite a bit.
Since ra_neon does not have that code reuse as a goal, it
unconditionally relies upon svn_txdelta_to_svndiff3 which is a wrapper
around zlib and then base64-encodes the whole svndiff3 output before
sending it on the wire. Therefore, ra_neon can't avoid compressing
the fulltext on the wire unless you set SVNCompressionLevel to 0. So,
what we see on the wire with ra_neon is always the compressed fulltext
base64-encoded - so, of course, ra_neon's traffic will be smaller than
if we disable mod_deflate for ra_serf. To be clear, in this scenario,
ra_neon is still doing a zlib pass while ra_serf is not doing any
compression. However, keep in mind that ra_neon is actually *helped*
from a network-traffic perspective by mod_deflate as
double-compression mitigates the base64 space penalty...but, that's
still sub-optimal from perfect network conditions as we are deflating
a base64 representation of something that is already deflated. By
removing this indirection and inefficiency, I think we can ultimately
get closer to the ideal network conditions with ra_serf than with
ra_neon.
Also, keep in mind that svn and mod_deflate have different default
zlib compression level defaults (5 vs 6). Part of any skew could be
that SVN defaults to 5 and mod_deflate defaults to 6...so, it may not
be quite symmetric. As Daniel pointed out, most web servers today are
not going to be CPU-bound - they are typically network and I/O bound.
And, many many large sites will do deflate at the edge anyway...so,
they would incur the zlib penalty elsewhere.
Again, the outstanding optimization to do on the ra_serf side is to
reduce the number of PROPFIND requests and make that not proportional
to the number of files - most likely either to the number of
directories or only when custom properties are set. -- justin
Received on 2012-05-17 09:43:44 CEST