Performance Tips

Miscellaneous Performance Tips for Large Sites

Summary

This article contains miscellaneous performance tips for large sites.

Details

• Be sure to read "Preventing Server Swamp" in Chapter 7, "Tuning for Performance," of the Perforce System Administrator's Guide. Most of the following tips are detailed in that chapter.
• If you're on an older Perforce release, consider upgrading. Each release of Perforce offers more performance improvements. See our Downloads page for the current release version.
• Slow response time is not usually a symptom of inadequate server machine resources. It is more likely a symptom of unnecessary database locking caused by:
  • Inefficient scripts
  • Unrestricted client views and lack of protections in large depots
  • Naive users unwittingly issuing commands on very large datasets
• Except for database locking, all Perforce Server activity is asynchronous and parallelized. During peak hours at large sites, the combination of user requests and scripts running against large datasets could cause excessive paging on the server machine. Schedule large operations (recreating huge labels, syncing huge workspaces from scratch, etc.) during off hours. If that's not possible, contact Perforce Technical Support for advice on strategies for "side-tracking" large Perforce Server requests.
• Checkpointing locks the Perforce Server's database. If your Perforce Server's database is so large that checkpoints take a noticeable amount of time, run your checkpoints during off hours so users are not affected. If that's not possible, contact Perforce Technical Support for advice on doing offline checkpoints.
• The Perforce Server can make use of whatever machine power is available. If your Perforce Server is going compute-bound, consider upgrading to an SMP ("symmetric" multi-processor) machine.
• Really complicated client or branch views can take some time to process (e.g. if there are 100,000 files to run through a 300 line branch view, it can take a minute or two). Try to avoid using complicated views. (It's easier on users, too.)
• Use p4 obliterate during off hours and as a last resort only.

  In 2004.2 and earlier releases, if you have very large depots, obliterate can take hours to run, locking out users the whole time. 2004.2 and earlier servers scan the largest database files in their entirety once for each argument on its command line. (You can reduce the obliterate command line arguments to 1 using the "temporary client trick" described in Chapter 7 of the Perforce Administrator's Guide.)

  In 2005.1 and later releases, obliterate is faster. 2005.1 and later servers use more efficient algorithms to probe the database files for data to delete, rather than scanning the files. In the 2005.1 release, one of the algorithms benefits from each client's MapState that is set, so ensuring that every client's MapState is set will result in the fastest obliterate. (MapState was last present in the 2005.1 release. 2005.2 and later releases are optimized without needing MapState, so it no longer exists in 2005.2 and later releases.) In the 2005.1 release, every client's MapState can be set using the following bash shell commands from a *nix client:

    p4 clients \
      | sed 's/^Client \([^ ]*\).*$/p4 -c \1 fstat \/\/depot\/file/' \
      | /bin/sh > /dev/null 2>&1