On Tue, Apr 14, 2020 at 10:25 AM Carmen Alzzer <car...@gisit.dk> wrote: > > helo friends, > while this is still hot on here - can you please tip in how your MPM are > handled? also if you have thoughts upon reading my setup, i would be > delighted to hear from you :) > > cheers > Carmen
Hi Carmen, [ Sidenote: we prefer "bottom-posting" or "inline replying" on this list. ] I have never looked at tweaking the MPM myself, and I have not yet seen much discussion about it here. We're using the defaults of our distribution (we use a CollabNet package of SVN, which includes httpd 2.2.23), which is prefork (with default settings). We're running it on a VM with 4 Intel Xeon CPU's and 8 GB RAM, running Ubuntu 16.04. I think the MPM will not be a big performance factor in most cases. IMHO the things with the most impact on performance are not MPM-related (and some are more client related). So, following Stefan, I would suggest first making sure the "known performance knobs" are in order. I'll try to give you "my list" here below. In my experience, the most important things for SVN performance are: Server side: - httpd config: MaxKeepAliveRequests 10000 (or higher, we use 20000) [1] SVNInMemoryCacheSize 131072 (=128 MB -- or higher if you have enough RAM), or some suitable value [2] Cache authentication results (LDAP caching) (though I believe this is less important if KeepAlive works well) - If you don't need path-based authorization, disable it (SVNPathAuthz off). If you have to use path-based authz, try "SVNPathAutzh short_circuit" [3]. - FSFS back-end must be on fast storage, accessible by the server as a local disk (not NFS / SMB mounted -- that's way too slow) - Use FSFS format 8 with lz4 compression, and do a full dump & load to this format if you can. (see [4] for a step-by-step guide) - 'svnadmin pack' your repositories regularly (we use a nighly cron job for this) - If you have problems with commit performance, check your hook scripts (start-commit, pre-commit, post-commit) for any custom code that could be slowing things down too much (be very careful if you loop over all changes in a commit, and do $stuff for every modified / added / deleted file ... this scales with the size of your commit, so make sure $stuff is as fast as possible, and avoid unnecessary work (early-exit wherever you can)). If you're not sure, try to inject some measurement code in your hook scripts [5]. Client side: - Make sure they use recent clients! At least 1.10, preferably even the latest (1.13). - If a working copy acts really slow, ask them to run "svn cleanup" (cleaning up the pristine store, and most importantly fixing the timestamps of the files in the svn metadata). This is especially important if they have copied over their (large) working copy from one disk to another (depending on how this is done, this gives all files a new lastmod-time, which makes the working copy very slow because svn cannot use its metadata anymore as a shortcut to see if a file was modified ... it has to read + checksum every file on many operations). - Avoid using working copies on networked drives (NFS, CIFS, ...). This can be really slow. - If you really must use a networked location for your working copy, try if it helps if you put "exclusive-locking = true" in the [working-copy] section of the ~/.subversion/config (*nix) or %APPDATA%/Subversion/config (Windows). [6] Client-Server network: - Be very wary of proxies etc. If you're running a corporate installation, try to arrange that your clients can connect directly to the svn server. - On a LAN, of course wired works best (1 Gbit, or even 100 Mbit). But wireless (if enough capacity) works fine too. These days, most of our users are working from home over VPN, and that works very well too. [1] https://subversion.apache.org/docs/release-notes/1.8.html#neon-deleted [2] https://subversion.apache.org/docs/release-notes/1.7.html#server-performance-tuning [3] http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html#svn.serverconfig.httpd.ref.mod_dav_svn [4] https://subversion.apache.org/faq.html#dumpload [5] I'm using this helper code in my pre-commit hook (in Bourne shell): [[[ DEBUG=1 logStart() { if [ $DEBUG ] then START_DATE=`date +'%F %T'` START=`/usr/local/perl/bin/perl -MTime::HiRes -e 'print Time::HiRes::gettimeofday.""'` AUTHOR=`$SVNLOOK author $REPOS -t $TXN` CHANGED=`$SVNLOOK changed $REPOS -t $TXN` export CHANGED # Export so it can be reused (other scripts check for this variable) NR_CHANGES=`echo "$CHANGED" | wc -l` fi } # logEndAndExit $exitCode # Logs the end of the script with timing information, and exits with $exitCode logEndAndExit() { EXIT_CODE=$1 if [ $DEBUG ] then ELAPSED=`/usr/local/perl/bin/perl -MTime::HiRes -e 'printf ("%.3f", Time::HiRes::gettimeofday - $ARGV[0])' $START` # start-datetime end-datetime author nr-changes txn-key exit-code elapsed-millis echo "$START_DATE\t`date +'%F %T'`\t$AUTHOR \t$NR_CHANGES\t$TXN\t$EXIT_CODE\t$ELAPSED" >> $REPOS/hooks/logs/pre-commit.log fi exit $EXIT_CODE } logStart # Do useful stuff. If exiting with an error, invoke logEndAndExit $errorcode logEndAndExit 0 ]]] (of course, make sure the $REPOS/hooks/logs directory exists and is writable by the server process) In the post-commit hook I have similar code, except using $REV instead of $TXN, and writing to post-commit.log instead of pre-commit.log of course. In the start-commit log I only have this simple line to track when it was run (the contents of the script are negligible): START_DATE=`date +'%F %T'` echo "$START_DATE\t`date +'%F %T'`\t$USER" >> $REPOS/hooks/logs/start-commit.log You can use the users and timestamps, and $TXN and $REV numbers to correlate things to each other, so you can see when a particular user entered the start-commit phase, and started and left the pre-commit and the post-commit. That's useful when investigating concrete complaints. Further: the time between start-commit and pre-commit is also quite interesting, as that's the point when file contents are being transferred and a transaction is built up on the server; and time between pre-commit and post-commit is the time the server needed to make an actual revision out of the transaction. [6] https://subversion.apache.org/docs/release-notes/1.8.html#exclusivelocking PS: If someone wants to add this to some (wiki) page, faq, ... go right ahead :-). -- Johan