[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Issue 3980] serf increases server load

From: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Thu, 15 Nov 2012 13:38:21 +0100

On Thu, Nov 15, 2012 at 12:36 PM, Branko Čibej <brane_at_wandisco.com> wrote:

> On 12.11.2012 19:46, Ivan Zhakov wrote:
> > On Mon, Nov 12, 2012 at 10:27 PM, Bert Huijben <bert_at_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
*
Received on 2012-11-15 13:39:00 CET

This is an archived mail posted to the Subversion Dev mailing list.