On 13 Mar 2006 16:09:33 -0600, kfogel@collab.net <kfogel@collab.net> wrote:
> > I believe that most of the 'common' checkout/update/diff/status, log,
> > blame, and commit functionality is now working and loosely tested (as
> > in 'works for me'). SSL, deflate, basic auth, etc. all work.
>
> How is speed against ra_dav?
By and large, it's competitive. Out of the box, serf currently
#define's SERF_DEBUG_BUCKET_USE. This enables a bunch of expensive
debugging checks - but without it, it's usually within a few seconds
in my tests.
For a checkout of svn @ r17500 without serf's debugging code:
ra_dav
2.66user 1.07system 0:41.25elapsed 9%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+1612minor)pagefaults 0swaps
ra_serf
3.80user 7.38system 0:42.99elapsed 26%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+3111minor)pagefaults 0swaps
So, that's 42:99sec (ra_serf) versus 41:25sec (ra_dav). I would also
expect that for higher-latency connections, multiplexing a checkout
over multiple connections may be a performance win too.
Also consider that ra_dav is doing essentially O(1) requests (one big
REPORT with base64'd content) where ra_serf is doing roughly O(2*n)
requests (one REPORT and a PROPFIND/GET for each file + PROPFIND for
each dir). I'll note that because of the much higher number of
requests, the logging system of httpd can also become a noticable
bottleneck for some cases.
I'm planning to complete the regression tests and then come back to
see if we can get more performance and lower the memory footprint
further. We may be able to do a 'Depth: 1' PROPFIND per directory
instead of PROPFIND per file; this matches how ra_dav used to do it.
Our memory footprint is roughly equal to the pipeline depth. I think
the higher CPU usage has somewhat to do with the higher memory
footprint. But, the overall performance is close enough that I want
to focus on the regressions now.
HTH. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 14 06:06:08 2006