[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: "svn diff" performance

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-07-24 14:42:36 CEST

Vladimir Prus <ghost@cs.msu.su> writes:

> I've looked at ethereal log for the case of localhost. Unless I've missed
> some packets the situation is: client and server talk for a couple of
> seconds, then wait for a long time, and then server closes connection.
> What can be the problem?

Here's how a server-side diff works:

  * the client sends a REPORT, claiming that it has revision X, and
    that it wants to update to revision Y.

  * the server sends a response to the report: just a single xml tree
    that describes which files need to be updated.

  * for each file mentioned in the xml response, the client does two
    GET requests. It pulls down two fulltexts of the file into a
    temporary area, diffs them locally, then deletes them.

This process works identically over ra_local or ra_dav. But it's not
a surprise at all that the ra_dav is much, much slower.

In the ra_local case, all conversation is happening in memory: the
initial report and response, as well as file fetching. Berkeley DB is
being used directly by the client to suck files from the repository
into the temporary area.

In the ra_dav case, we're talking about multiple network turnarounds.
*Two* http GETs for each file that has changed.

In your comparison, you're testing file:/// vs. http://localhost. I
would still expect the http version to be slower, although maybe
you're right -- maybe it's too slow. Do you have reason to believe
that apache is 'hanging' or something? Do you see the GET requests in
ethereal? Where does the 'delay' happen?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 24 14:44:13 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.