On Tue, Nov 22, 2005 at 12:34:34PM -0500, Greg Hudson wrote:
>...
> I'll note that better caching benefits could be obtained using a
> Subversion-specific mirroring mechanism (the svn_ra_reply functionality
> is a good start here, as it allows such mirrors to operate in pull
> mode). You'd get better performance here because the mirror could
> handle arbitrary requests for diffs between versions, while the cache
> could at best only handle the ones it's seen recently.
True. But I'll note that certain diffs will be common. Consider 10
revisions which update a total of 100 files. Those hundred diffs will
be cached, so anybody updating from anything in HEAD-10 to HEAD will
get the cached diffs to bring them up to HEAD.
The trouble is in the one-off diffs for diff/merge requests or for
people that go a long time between updates. Those will have to hit the
server in the HTTP case, whereas your suggested mirror could probably
satisfy them.
> A mirror might consume more disk space than a functional cache (or it
> might consume less in some cases), but someone setting up a
> high-performance network isn't generally limited by disk space.
Agreed.
> 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.
Creating a custom mirroring system is a lot of complexity in its own
right, so I don't think it saves anything [in the HTTP environment
we're talking about]. Sure, it solves one unique problem, but an HTTP
cache can improve a lot of your browsing experience, too.
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. 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. I would
worry about the same kind of thing affecting any custom mirror/cache
solution.
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.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 23 11:01:42 2005