On Wed, May 16, 2012 at 12:12 PM, Philip Martin <[email protected]> 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
