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

Re: Server choice?

From: Lieven Govaerts <svnlgo_at_mobsol.be>
Date: 2007-10-19 09:00:39 CEST

Moore, Tom wrote:
> I have the option to install Subversion on Solaris on a Sparc, Solaris
> X86, or on Linux. I was looking to see if there was any anecdotal
> evidence out there supporting one platform over the other (other then
> the obvious expense of a Sparc vs a x86 platform)
>

One of my customers has decided to move from Suse SLES 9/x86 to Solaris
10/UltraSparc 4+ last year. They're managing about 110 repositories with
60GB of data for 500 users. I was there at the time managing the
migration to Subversion (from PVCS).

The reasons we decided to start this migration were:
1. Their new SAN infrastructure wasn't certified for SLES 9, so they had
to keep all repositories stored on local (RAID) disk.
2. Solaris has built-in zones (virtualisation) which makes it easier to
customize some of the packages needed by Subversion without breaking
other applications (OpenLDAP specifically).
3. The Sun servers are clustered over two data centers, and since they
use Subversion for a whole lot more than source code management it's
really important the server and data is available 24x7.
4. The operational support of Subversion was handed over from our team
to an operations team, but those were more experienced in Solaris than
Linux.

The above reasons are specific to that company, one can also set up
virtualisation solutions for linux and cluster linux servers, that
customer just didn't have that for linux at that time.

The migration to Solaris took some time. The team doing the packaging
and installation had to:
- build apache, Subversion and all its dependencies, OpenLDAP and Python
from source.
- package those using Sun's archaic packaging software.
- try some gcc options to get the best performance.
- write an apache plugin to integrate with the cluster management software.

During acceptance testing of the new solution we found out that the
Solaris/UltraSparc setup was considerably slower (20-25%) than the
Linux/x86 equivalent in low load scenario's. Otoh, when increasing the
number of concurrent users the performance for each user stayed level.

Now if you look at the load of the Linux setup, while there are 500
users using Subversion on a daily basis, the actual access to the server
is limited to about 5 concurrent requests handled at any time. The Linux
server was perfectly capable to handle this with the CPU's it had on
board, but once people started merging the users noticed performance
decrease.

One reason for Solaris being slower than Linux in the 5 concurrent users
load scenario was the migration from local disks to SAN. The main reason
however is that the Sparc IV+ CPU on its own is slower than x86. But,
because of its 16 CPU's, it did scale much better to higher loads.
Things were improved by 10% by changing gcc parameters, but that
introduced some instability so that version never reached production.

Concerning the SAN performance, Subversion 1.5 introduces an option to
specify the location of its transaction files. That can be used to store
transactions files in the /tmp partition (stored in RAM) which will
improve the performance of commits. There are other performance
improvements in svn 1.5, including better node caching, so the 20-25%
gap with the old Linux setup might be reduced quite a bit.

The Subversion on Solaris/Sparc IV+ has been in use in production for
almost a year now, and I have to say, it has been rock solid! Subversion
on its own hadn't given any problems before, but the automatic fail-over
 to the second node in the cluster has been needed two or three times.

I hope any of this is useful information to you.

Lieven

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Oct 19 09:21:19 2007

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.