[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: Mark Phippard <markphip_at_gmail.com>
Date: Thu, 15 Nov 2012 08:20:52 -0500

On Thu, Nov 15, 2012 at 6:36 AM, 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.

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/
Received on 2012-11-15 14:21:27 CET

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