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

Re: general server performance (was Re: apache svn server memory usage?)

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-07-01 17:42:43 CEST

Chris Hecker <checker@d6.com> writes:

> I should be clear that I'm not complaining here, I know svn is still
> in development, premature optimization and all that. I'm just
> wondering if there's something I've screwed up as the server admin or
> if this is all stuff that code changes will be necessary to fix.

I have some strong opinions here, and I'll state them at the risk of
Greg Stein coming at me with an axe. :-)

I think there are two fundamental problems regarding the "slowness" of
ra_dav/apache, compared to, say, ra_svn/svnserve:

1. HTTP is a stateless protocol. It's just *not* the best choice in
   the world for something like version control, no matter how you
   drink the kool-aid. Even though the client keeps a single TCP/IP
   connection open to apache, there are still a whole lot of network
   turnarounds, and the requests/repsonses are pretty "thick" with

   Now granted, at the moment, we've not yet optimized ra_dav nearly
   as much as we can. It's still sending too many requests and
   turnarounds, waaaay more than it should. And it will be fixed.
   And HTTP proxy caches will speed things up as well. But deep down,
   I still believe that HTTP will never be quite as fast as our custom
   stateful protocol.

2. As was already mentioned, because HTTP request is stateless, apache
   opens and closes/syncs the repository (BDB environment) with
   *every* request. (One user had write caching turned off on his
   server; this caused his http checkouts to arrive about 1 file
   every 2 seconds!) There's been discusion about keeping the
   repository open for the whole TCP/IP "connection session", and
   Sander has experimented with this, but it didn't seem to do much.
   Still need to investigate.

At the moment, there's still a tradeoff decision to be made. If you
use apache, you'll get slower performance than svnserve, but you get a
zillion other great features in return (no unix accounts required,
almost any sort of authentication, path-based authorization, some
degree of webDAV interoperability, etc.) I think it's worth the trade
for most people.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 1 17:44:14 2003

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.