On 5/18/07, Andrew Close <aclose@gmail.com> wrote:
> i'm trying to put together a list of hardware (client & server) and
> network requirements for the various SCM tools we're evaluating.
[snip]
Subversion uses minimal processor and memory in general. The main
resource hogs on the server side are Apache if you use http/s: access,
and PAM and/or LDAP for any authentication setup, so look to those
projects for resource minimums. Storage and network are the primary
resource concerns here, and in my opinion storage is far cheaper than
network, so I always balance things to use far more storage than
bandwidth. That's one of the reasons I use SVK on the client side --
it uses a bit more storage capacity, but far less disk IO (capacity is
much cheaper than speed), and running "svk sync -a" on a regular
schedule spaces out the network bandwidth use.
SVN network speed is very good, due to the consistent use of
diffs, especially if you use SVN 1.4 or higher end-to-end.
Update/commit cycles tend to happen in bursts, so that always creates
traffic bursts, where the network bottleneck is at the server.
Load-balancing configurations are starting to emerge to help deal with
this.
Look at the type of SVN client you will be using, for your
client-side resource calculations. SVK is command-line only, and
maintains a mirror of the entire Subversion repository locally on each
client, so it uses a lot of disk capacity at the client, and very
little else. SVK's use of Perl does add a little overhead at run time,
and certain star merge operations can get processor and memory
intensive. On Windows, TortoiseSVN constantly uses a little processor,
memory, and lots of disk IO, because it is constantly caching status
data from individual .svn folders, to keep icons up to date. GUIs
always use more resources. The SVN command-line client only uses a lot
of disk IO when completing any transaction, again due to all the
little .svn folders everywhere. On Windows, the heavy use of NTFS IO
calls adds its own overhead, which is very difficult to calculate. I'm
hoping things are swinging towards one big .svn per checkout in future
versions, which would improve disk IO if nothing else, but I'm not
holding my breath.
:) Jred
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 18 21:57:12 2007