- Be sure to read "Tuning Perforce for Performance", in particular the section "Preventing Server Swamp" in the "Helix Versioning Engine Administrator Guide: Fundamentals" document. Most of the following tips are detailed in that chapter.
- If you use 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. Slow response time is more likely a symptom of unnecessary database locking caused by:
- Inefficient scripts
- Unrestricted client views and lack of protections in large depots
- 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, and so on) during off hours. If it is not possible to schedule large operations for off-hours, contact Perforce Software's Technical Support team 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 it is not possible to run checkpoints during off-hours, read the Offline Checkpoints KB article for advice on doing offline checkpoints.
Should you be unable to schedule some of the large operations or checkpoint creation during off-hours, contact Perforce Software's Technical Support team
to discuss strategies for 'side-tracking' large operations and offline checkpointing.
- 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 (for example, 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. Less complicated views are easier on users, as well.
- 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 by using a temporary client workspace, as described in the documentation here.)
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 results 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