[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-17 16:31:33 CET

On 2/17/06, Phillip Susi <psusi@cfl.rr.com> wrote:
> Aye, I was wondering the same thing. As long as you keep the
> connection(s) pipelined so they are always pushing data as fast as they
> can, then one is better than many since the many will compete with each

Again, HTTP connections are ideally stateless - so, we can't have a
very deep pipeline before the server decides to kill us off.

The most optimum solution from the client's perspective is to open
#-of-files-to-get/pipeline-depth connections to the server. That's
unrealistic, so we cap ourselves to 4. =)

> Seeing as how the one test done on a local server that isn't sharing
> bandwidth with other users turned out to be slower than ra_dav, that
> tends to support my theory. A single connection is more efficient, but
> using multiple connections on a heavily used server enables you to steal
> more bandwidth from other users. This is not a very good idea. If you
> start using 4 connections to steal more bandwidth, then someone else is
> going to start using 5, then 6, and so on. Eventually the server will
> be hit with so many connections that at best, a lot of collisions will
> happen and everyone's throughput will drop, and at worst, the server
> will take a dump from the overload.

If you kept it at one connection, you'd have lengthy delays where
there is no network traffic because you're constantly reopening the
TCP sockets. This isn't ra_svn which assumes a persistent TCP
connection for the lifetime of the RA session. -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 17 16:45: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.