Sorry, I forgot to CC the users list on my previous reply. I'll answer your
questions first, then append the previous note.
+ Server: OS 10.3. Subversion v 1.0.2
+ Client: Win XP, fast hardware, NTFS. 2 Subversion clients (similar
results with each): Tortoise, svn command-line client. Both are the ones for
svn 1.0.2.
+ Access via svn+ssh. Normally with key agents, but using manual password
for timing (so I can tell allocate time to a finer granularity). Total time
similar with keys and passwords.
+ Clients run both virus scanner and firewall (standard corporate config).
I haven't collected the data already, but I can regenerate it, given time.
Before I do so, however, I can give you estimates. Each estimate gives three
times. The first is the time before the client prompts me for my ssh
password. The second is the time performing the operation. The third is the
time starting when the operation states its result and ending when the
client process exits.
I use both tortoise and the command-line clients. The times are similar for
both clients. All operations are done from the root of a tree with around
25K folders and 1.5GB of files.
Operation 1: Update when already up to date: 10 min / 5 sec / 5 min
Operation 2: Commit (changed one 25 byte file, in top dir): 10 min / 10 sec
/ 5 min
Operation 3: Cleanup, after killing an update while it is asking for ssh
password: 5 min
When performed on smaller subtrees, the first and third measurements drop
drastically. I have not performed experiments to determine whether the
durations are due to the number of files (lots) or the number of folders in
the subtree. Timing results are certainly proportional to size of subtree,
but have not measured, so don't know O() for the algorithm.
Performing the same operations on the same system but with smaller subtrees
(eg, 3 directories & 10 MB of data files) result in times like the
following:
Operation 1: 2 sec / 5 sec / instant
Operation 2: 2 sec / 10 sec / instant
Operation 3: instant
"instant" means too small to measure. May be as long as 1 sec, from time to
time.
Let me know if you want accurate, complete data. It'll take me a while to
generate and record it, so I'd rather not if you can get by without it.
Thanks for looking into this. We chose svn partly for its performance, and
this is the only place where its performance hasn't been all that we
desired. Thanks for producing a good product.
Arlo
-----Original Message-----
From: Erik Huelsmann [mailto:ehuels@gmail.com]
Subject: Re: Svn scaling issue
On 14 Jan 2005 11:37:56 -0600, kfogel@collab.net <kfogel@collab.net> wrote:
> Could you give an exact transcript of the operations you tried, and
> how long they took, and anything else you noticed? I just want to
> make sure this really is the same problem as issue #1452.
Could you also - please - include:
- server platform (hardware / OS)
- client platform (hardware / OS / Filesystem)
- presence of a virusscanner on the client ?
- Subversion version you used
- Server access method (http://, svn://, svn+ssh://)
- any other component relevant to performance?
There are a real large number of variables here. Just stating
'Subversion is slow' is hard to help you with. Even with a transcript.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jan 14 20:15:58 2005