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

Re: Performance Results on Windows

From: Mark Phippard <markphip_at_gmail.com>
Date: Wed, 13 Aug 2014 17:03:06 -0400

On Wed, Aug 13, 2014 at 4:45 PM, Stefan Fuhrmann <
stefan.fuhrmann_at_wandisco.com> wrote:

It seems that CollabNET and other hosting providers possibly have one
>> of the worst configuration for log-adressing feature. Multiple users
>> access over HTTP to a number of gigabyte-sized repositories (so there
>> are no enough memory for enormous caches).
> Well, the key would be GB-sized projects (data
> transferred during export).
> I don't know how I feel about getting CollabNet involved.
> My concern is that they simply won't have the time to
> do it because we are not talking about "please, would
> you run those 2 commands for me?" but rather a two
> week effort.
Not to speak for Ivan, but I think he is simply saying that sites that are
hosting a significant number of SVN repositories are unlikely to be able to
benefit from some of the things like the large cache sizes.

I am not against making SVN faster in special controlled situations where
you can fine tune a server for performance. Just please do not make it
slower than it already is for the rest of us that cannot do that.

To give an idea from a recent server I am dealing with, there are
approximately 22K repositories with about 5.5 TB of data. They are served
via Apache with prefork MPM. There is no room for adding some massive RAM
cache to this, and I doubt it would help anyway.

FWIW, if the new format is primarily faster in specific situations, then
why don't we just not make it the default format and instead make you
specify a specific option when creating the repository to use the format?
 Then people can choose to opt-in to the format if they have an environment
where it will be useful and their server will be tuned accordingly?

Mark Phippard
Received on 2014-08-13 23:03:35 CEST

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.