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
headers.
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