On Wed, Nov 23, 2005 at 08:51:48AM -0800, Garrett Rooney wrote:
> On 23 Nov 2005 09:21:12 -0600, kfogel@collab.net <kfogel@collab.net> wrote:
> > Greg Hudson <ghudson@MIT.EDU> writes:
> > > 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.
And will always be slower. Can't do much better than a custom,
application-specific protocol. No argument there.
I've been talking about simplifying the system and improving the
overall capacity through caches. We can use normal GET requests and
PROPFIND and whatnot rather than custom reports.
>...
> I believe what ghudson means is that we've interleaved the diffs
> and/or file contents with the rest of the data we're getting back,
> just as we would if we had gone with the original scheme + http
> pipelining. So we've already got the kind of result we would have had
> if neon had pipelining, and it's still slow.
Right. But we've also thrown out the ability to increase capacity
through the use of caches. Certain operations can also be satisfied
much closer to the client, thus reducing some latency. The server can
use caches to improve overall capacity (much faster and less resource-
intensive to serve off disk than to compose diffs to generate a
response).
> Of course, there are certainly other reasons that ra_dav is slow (lets
> make a million PROPFIND requests before we do anything! ok! how
> about we base64 encode all binary data so it's bigger than it has to
Note that the base64 encoding is because we embed the content into a
big-ass XML response. Switching over to the GET form allows us to send
the content to the client in its original binary encoding.
What operation are you referring to which does all the PROPFINDs?
> be! great! etc.) so perhaps it's worth moving towards a custom
> protocol that uses http, is built with the possibility of being http
> cache friendly, but doesn't fall victim to the problems we currently
> have with DAV.
Feel free, but I think there is ample room for improvement by moving
back towards "plain old HTTP/DAV" than to increase the customization.
As mentioned before, you could always tunnel the svn protocol, or
something close to it, over an HTTP pipe. Dunno how cacheable that
would be; I guess you could always do more protocol design work...
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 Nov 24 11:50:27 2005