On Mon, Mar 28, 2011 at 18:14, Philip Martin <philip.martin_at_wandisco.com> wrote:
> Mark Phippard <markphip_at_gmail.com> writes:
>
>> There is one issue that I want to raise that I do not think is an
>> outlier. I was expecting HTTPv2 to yield significant improvements,
>> and so I stopped the Apache server after each test so I could grab its
>> logs. I wanted to be able to show how much the HTTP traffic was
>> reduced. I have not done this yet, but for Serf it looks like the
>> logs were bigger. The issue I want to raise though is about Serf in
>> general. Running these benchmarks with Neon yields an Access log of
>> about 102KB and a Subversion log of about 3KB. Running the benchmarks
>> with Serf yields an Access log over 12MB and a Subversion log over 5
>> MB.
>
> Yes, we discussed this earlier this month. Serf makes more requests
> than neon for checkout/export/update, a GET and PROPFIND per file versus
> a single custom REQUEST. My measurements using Subversion trunk as a
> dataset showed serf slightly faster than neon. John's measurements with
> part of the Linux source tree showed serf slower than neon. When I
> switched to his dataset I got the same result as he did. The obvious
> difference between the datasets is that his was about half the size of
> mine but had about twice as many files. So the serf approach of making
> lots of requests appears to be less efficient on lots of small files.
I'd be interested to see whether the checkout speed is client-bound or
server-bound. I'm assuming it is client, right?
The multiple request approach allows the server to provide for more
clients simultaneously. Lots of smaller requests rather than chugging
on one big response. For even larger provisioning, multiple servers
against one filesystem can service yet more clients simultaneously.
It also helps with proxying/caching, though Mark says SSL obviates
that (which I dispute, but it *is* valid to note that it is uncommon
and tricky to set up).
Lastly, the many-requests approach works better if the connection
drops for some reason and needs to be restarted. ra_serf can request
the bits that were dropped, while neon has to restart the whole
process (though I'm not even sure that neon has automatic
re-connection logic).
Cheers,
-g
Received on 2011-03-29 00:24:20 CEST