On Thu, Nov 15, 2012 at 6:36 AM, Branko Čibej <br...@wandisco.com> wrote: > On 12.11.2012 19:46, Ivan Zhakov wrote: >> On Mon, Nov 12, 2012 at 10:27 PM, Bert Huijben <b...@qqmail.nl> wrote: >>> Any idea why a 1.8 client would use more than twice the amount of >>> data of 1.7? It should send out less requests than a 1.7 client; >>> especially to a 1.8 server where we avoid property requests. >> svn 1.8 uses raw GET for fetching files, so it downloads uncompressed >> unless you have mod_deflate enabled. While neon uses svndiff format >> for transmitting files content which self-compressed. > > I don't buy that argument. Generating svndiff takes CPU, too. What's > more, the simplest kind of svndiff is just a "new" op and > zlib-compressed data, effectively having the same characteristics as > mod_deflate. > > Why would mod_deflate use more CPU cycles per compression ratio than > svndiff1? Unless you're testing with mod_deflate compression level set > to 9, which would be silly for this kind of stream compression.
See this reply from Justin earlier this year: http://svn.haxx.se/dev/archive-2012-05/0343.shtml "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." I thought the latest results show that Serf uses less server CPU? So why are we still discussing this aspect? I guess we can stil make Serf better here, but it is already better than Neon if this is the measuring stick. If mod_deflate is not used, then Serf uses considerably less CPU than Neon but sends significantly more data. If mod_deflate is used, it uses slightly more CPU than Neon does (without mod_deflate) and sends significantly less data. My main concerns are areas where it may catch server admins unprepared: * Explosion in HTTP requests == explosion in log file sizes. Even with good log rotation, companies that need to retain their logs will require a lot more disk storage than they have in the past. * Increase in HTTP requests/connections could stress authentication systems that do not implement some kind of connection-level caching. -- Thanks Mark Phippard http://markphip.blogspot.com/
