On Mon, Nov 21, 2005 at 01:13:02PM -0500, Greg Hudson wrote:
> concept, not necessarily in syntax). We would probably get much better
> performance that way, although we'd be throwing out any hope of using
> generic caching HTTP proxies to improve svn performance. Which is okay,
> since you can't do that today and it's unlikely anyone would be able to
> derive much benefit from it in the future.
Remember that one of the big overhauls in httpd 2.2 (that we're voting
on over in dev@httpd) is the cleaned-up caching support.
Enabling HTTP caching through mod_disk_cache for Subversion would be a
big win (at a cost of disk space for sure though) as we could bypass
almost everything that Subversion and Apache does today. It probably
*does* work today with httpd 2.2 (as SVN sends the L-M headers on GET).
There might have to be some work done to allow caching of PROPFIND and
PROPGET and other read-only operations.
If Subversion were to switch to a custom protocol that isn't RESTful, it
will mean that there will never be any chance of taking advantage of
caching. The METHODs won't mean anything any more, so they can't be
intelligently cached by an intermediary. Locking that out would
certainly be a bigger performance penalty than anything you can hope to
achieve with our own protocol as mod_disk_cache would totally eliminate
any XML generations, fs access, etc. This is the trap that some SOAP
folks have and why they can have extreme scalability issues. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 22 01:23:16 2005