On Thu, May 12, 2011 at 2:12 AM, Justin Erenkrantz
> On Wed, May 11, 2011 at 4:40 PM, Mark Phippard <markphip_at_gmail.com> wrote:
>> The story using Serf is not as good. There are a few places where it
>> is fastest, namely merge. But there are other cases where it is
>> dramatically slower. The number of HTTP requests with Serf is 80,990.
>> Looking at the numbers, it seems like Serf is slowest when it comes
>> to the areas where it issues all those GET requests, such as checkout
>> and update. On other operations it is more inline with Neon. Maybe
> r1102173 will help slightly when there are lots of checkouts as
> ra_serf wasn't asking for the REPORT response to be compressed - doing
> that saves a fair bit of traffic before the parallelization can begin.
> (86k down to 16k for a checkout of notes/.)
> I'm also assuming you've appropriately configured your httpd server...see:
> FWIW, in some quick local real-world tests, I see ra_neon and ra_serf
> being within margin of error on checkouts - so I have a hunch it might
> be something more pathological that a test suite would hit. I'm sure
> those of us in Dublin or Berlin can look more. I'll be in Dublin this
> weekend, but I won't be in Berlin... -- justin
I re-ran the results with your latest changes and posted the new numbers.
I also turned on mod_deflate. I do not normally use it for the reason
I also changed MaxKeepAliveRequests from 64 to 5000
The numbers are a little better. There is on anomaly in the
FolderTests where an update blew up from 2 seconds to over 10 minutes.
I had this problem one other time when running with Serf. I am not
sure what goes on when that happens. Maybe something similar happened
with the initial checkout when it went from 20 minutes to 2 minutes?
I am currently running the Neon tests again to while I have
Received on 2011-05-12 16:23:31 CEST