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

Re: Svn scaling issue

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-01-14 20:20:10 CET

Just as an aside, have you tried measuring speed using a 1.1.2 client
and server?
You really shouldn't be using 1.0.2, it's quite old. There have been
quite a few performance fixes.

On Jan 14, 2005, at 1:08 PM, Arlo Belshee wrote:

> 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

---------------------------------------------------------------------
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:23:10 2005

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

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