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

Re: Preferred Subversion 1.13 MPM

From: Stefan Sperling <stsp_at_elego.de>
Date: Tue, 7 Apr 2020 09:43:40 +0200

On Tue, Apr 07, 2020 at 12:05:49AM +0200, Carmen Alzzer wrote:
> hi guys,
> so im starting to tune a Subversion installation, that runs slow on merges.
> So im starting looking into apache MPM - current its setup to event MPM in
> Apache2.4, but i figure it perhaps should be preforked. Whats your
> recommmandations ?

What makes you think changing the MPM would solve the problem?
> the installation is 80GBcode in 150+ repos - apache 2.4.43 and im upgrading
> subversion from 1.12.2 to 1.13 tomorrow - it runs on FreeBSD 11.3 and theres
> on LAN traffic going through http, and traffic is on an average day 700.000
> requests to the webserver all inclusive :)
> The developers are complaining that merging takes way too long and theyd
> rather shift for git enterprise bling bling. any help is much appreciated :)

You're not providing much details but I'll write a list of common problems

Keep in mind most of the work performed during merges occurs client-side.
If people are running old clients, ask them to upgrade.

There are some server-configuration factors which can increase latency
between client and servers, or which affect server-side performance in
general, and those could be relevant:

- Make sure that authentication is fast. You're not providing any details,
  but if you're using a centralized service like LDAP or AD make sure that
  the SVN server will get a response from this service as fast as possible.
  Avoid configurations which result in per-request round-trips between SVN
  server and another server, and if possible even avoid such round-trips
  altogether. Cache authorized credentials! (e.g. use LDAP cache in mod_ldap)

- If the SVN server is talking SSL/TLS to any other service for any purpose,
  ensure that certificates are valid and avoid certificate revocation
  mechanisms that require sending additional requests like OCSP.
  (Especially if OCSP info in certificates somewhere in the chain points at
  a non-existent hostname it will add a lot of overhead; I have seen this
  in the wild with certs generated from AD)

- Configure high TCP Keepalive limits to avoid too many authentication
  handshakes (i.e. bump MaxKeepAliveRequests, see:

- Make sure that path-based-authorization rules with mod_authz_svn are used
  only to the minimum extent necessary. Lookups can be very expensive so
  ideally you'd only put path-based authorization rules in place if you
  need to *hide* something from the view of some users and otherwise let
  anyone who manages to authenticate read anywhere in the repository.

- If your performance problems are due to disk reads (i.e. you see a very
  heavy I/O load on the SVN server) tune your server's in-memory caching:
  And consider a dump/load of large repositories that aren't FSFS v7/v8 yet:
  And make sure to enable lz4 with FSFS v8 if you do a full dump/load cycle:
Received on 2020-04-07 09:44:04 CEST

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.