You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2006/03/13 22:09:33 UTC

Re: ra_serf update

"Justin Erenkrantz" <ju...@erenkrantz.com> writes:
> Just a quick note to summarize where I am with ra_serf.
> 
> Short summary: My commits since last Friday have been with ra_serf.

Niiiice!

> 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?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ra_serf update

Posted by kf...@collab.net.
"Justin Erenkrantz" <ju...@erenkrantz.com> writes:
> 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.

Sure, sounds like sensible priorities.  If ra_serf is already
competitive even without any dedicated optimization work, then when
you really turn your attention to performance I'll bet there'll be a
lot that can be improved.

> HTH.  -- justin

It did!

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ra_serf update

Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 13 Mar 2006 16:09:33 -0600, kfogel@collab.net <kf...@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