On Wed, 2005-11-23 at 02:01 -0800, Greg Stein wrote:
> > So, while there's a certain elegance in being able to use generic HTTP
> > caching to improve performance, that elegance comes at a substantial
> > cost in the complexity of libsvn_ra_dav and--at least with the current
> > architecture--in the performance of the basic functioning of svn over
> > ra_dav.
>
> The complexity of the software increases, yes, but the user story is
> greatly simplified. Many places are already running caches of some
> form. Deploying squid is no big deal, and many people do that. HTTP
> caching proxies are well known items, and people have a great choice
> in how to install and configure those.
I dunno. If I'm, say, gnome.org, and my servers can't handle the
Subversion traffic, I think I'm more likely to want to set up a bunch of
mirrors than to point people at a bunch of Squid caches.
> Creating a custom mirroring system is a lot of complexity in its own
> right
With our architecture, not really. The hardest issue is rev-prop mods,
and it's not all that hard, although we could probably provide a feature
or two to make it easier.
> I'd much rather improve the client than to develop yet another server,
> with its own host issues related to networking code, security,
> documentation, logging, monitoring, and performance tweaking.
Are you imagining the mirror system would be yet another network server?
Much more likely, it would be one of our existing network servers
pointed at a mirror maintained by a cron job.
> When I
> look back at svnserve, the original idea was "small and light", but I
> note that it has grown a ton of functionality since then.
It has? It got path-based acls, but that was just moving logic from
mod_authz_svn (where it never should have been) into libsvn_repos, and
adding a few calls.
(I admit to some frustration at the amount of crud involved in having a
network server which satisfies everyone's needs, which svnserve
currently does not. I believe the answer is to encourage the creation
of better support libraries. I do not believe the answer is to
implement everything inside Apache httpd.)
> And besides, serf already does pipelining (and deflate/gzip and basic
> SSL). There are a ton of "friendly" bits that it is lacking, but the
> core is there. IMO, it is much more feasible to complete that thing
> and hook it into svn, than it is to write a new mirror system.
We already have the performance benefit of HTTP pipelining (at the
expense of giving up on generic HTTP caching), and ra_dav is still much
slower than ra_svn. I believe this mostly comes from wc-props and other
impedance mismatches between svn and DAV. Perhaps it's possible to fix
all of the resulting performance problems in other ways, but for years
now, no one who holds that theory has been writing much Subversion code.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 23 15:37:55 2005