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