On 15.11.2012 13:38, Stefan Fuhrmann wrote:
> 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%.
You may have a point there. The next question is, why would anyone want
to base64-encode a response to a simple GET? Seems like unnecessary work
for no good reason.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Received on 2012-11-15 14:08:53 CET