On Thu, Nov 15, 2012 at 12:36 PM, 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. > My guess / speculation without looking at the code: Neon: (txdelta against empty; almost nop) -> zip -> base64 -> send Serf + deflate: base64 -> zip -> send So, in neon's case, base64 is applied to less data then in the serf case. Since base64 inflates the data buffer by 1/3, serf also needs to zip more data then neon. The total CPU overhead would be somewhere between 30 and 40%. -- Stefan^2. -- Certified & Supported Apache Subversion Downloads: * http://www.wandisco.com/subversion/download *
