Ben Collins-Sussman wrote:
...
> we could make up yet another custom
> protocol response/request that only svn and mod_dav_svn would
> understand. We're already doing that in many places where subversion
> concepts don't line up with WebDAV/DeltaV. Doing it for the sake of
> performance gains would be a new policy. I don't think everyone is
> (yet) in agreement yet about this.
It would certainly be a tremendous gain for people who are trying to
do an svn ls -R over a low-bandwidth connection.
I repeated my benchmark with our current repository, which by now has
grown to 263182 entries, which is about twice the size it had during
my previous test. So it's now over 1GB of network traffic.
Even if I run svn list directly on our svn server machine
(AMD Athlon XP 3200+ running Linux), it now takes
Command being timed: "svn list -R http://svn/svn"
User time (seconds): 4317.76
System time (seconds): 99.78
Percent of CPU this job got: 60%
Elapsed (wall clock) time (h:mm:ss or m:ss): 2:02:21
I compressed the resulting list using bzip2, which works very well:
svn_list: 40.121:1, 0.199 bits/byte, 97.51% saved, 24246468 in, 604335 out.
So without redundancy, the net information I asked "svn list" for
is 604kB. It took "svn list" over two hours to get it to me and
it caused over a gigabyte of http traffic.
I know next to nothing about WebDAV/DeltaV and the XML data exchanged,
but would it not be possible to generate the 604kB of compressed data,
wrap it in XML and transmit that instead of over a gigabyte?
Carsten.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 19 15:35:09 2005