> -----Original Message-----
> From: sussman@collab.net [mailto:sussman@collab.net]
> Sent: Tuesday, July 01, 2003 8:43 AM
> To: Chris Hecker; SVN Dev List
> Subject: Re: general server performance (was Re: apache svn server
> memory usage?)
>
>
> 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.
I'm not too familiar with the methods subversion is using in its dav layer,
but I've definately run into the performance problems with checkout. Would
HTTP pipelining the requests be possible as a quick hack, i.e., no/minimal
dependency issues? I'd guess that would remove almost all of the
performance issues related to the network.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 1 21:43:27 2003