[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Status of ra_serf

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: 2006-02-18 19:39:46 CET

On 2/18/06, Phillip Susi <psusi@cfl.rr.com> wrote:
> I see. Then yes, it makes sense to limit the depth of the pipeline. My
> point though, wasn't that you should send 5000 requests at once, but
> that there is no reason you can't send them in batches of say, 25, and
> just keep sending more as the first requests complete, keeping the
> pipeline full the whole time. Why should the server close the socket
> and require you to reconnect to send another batch of requests?

You could send them in batches below the keepalive limit, but that's
not what serf does. serf will write up to the discovered keep-alive
limit or until we get EAGAIN then write up to keep-alive limit when
the socket becomes writeable again.

> > In order to stick the full-text in the XML response to the REPORT for
> > ra_dav, mod_dav_svn base-64 encodes every file such that it will be
> > valid XML parsable by expat. Base-64 encoding is moderately expensive
> > and increases the overall space; however, using mod_deflate lets us
> > recover some of the space at the cost of even more CPU.
> >
>
> Outch. That kind of sucks. I wonder if the REPORT couldn't just refer
> you to the files you could fetch in binary with GET rather than embed
> them in the XML response.

Yes, that's the strategy that serf is taking. Neon can't or rather it
used to, but the performance was abysmal since neon couldn't do async
or pipelining. The only thing neon could do efficiently was just
issue one large REPORT request. -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 18 19:40:42 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.