On Thu, Mar 14, 2002 at 10:25:16AM -0800, Darryl Okahata wrote:
> Greg Stein <gstein@lyra.org> wrote:
> > > 0. An organization wishes to maintain read-only mirrors of its
> > > Subversion repository. These are either to take the load of
> > > anonymous users off the master, or to reduce the bandwith demand of
> > > geographically-distant users at some expense in latency.
> >
> > Um. Why don't you just use a caching proxy for this? It is transparent to
> > the user, and drops a lot of load off the master.
>
> While the use of a caching proxy is pretty cool, two cases come to
> mind where caching proxies are suboptimal:
>
> 1. Performance. Over a slow/distant network link, it may take a while
> to populate/update the cache. With CVS, you can use cvsup or rsync
> (yuk) in a nightly cron job to get a read-only mirror; this way,
> during the day, local clients can access the read-only copy at full
> lan speed. With a caching proxy, the first client to hit the proxy
> can get a big performance hit, while the cache gets populated.
Yup. You can pro-actively pull content into the cache, to help ameliorate
the initial perf hits.
But your overall point stands: the caching proxy is not a replacement for an
optimized replication process and local store.
> 2. True disconnected operation (no LAN connection whatsover of any
> type). Caching proxies tend to insist on having a LAN connection ....
> ;-( In some cases, it's very nice to have a periodically-updated,
> read-only copy of a repository.
Yah... that would pose problems. Especially given that a caching proxy
cannot handle *all* requests to the server. It can serve up the bulk of the
content, but things like REPORT will definitely always flow through to the
server (thus, posing some latency problems). PROPFIND may or may not be
cacheable, depending upon the circumstance.
I think my point was that in a number of scenarios, a caching proxy will
help out quite a bit, and may even be a complete solution.
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 Thu Mar 14 21:37:13 2002