P4 Server performance tuning

Additional information on improving P4 Server performance can be found in the P4 Server Versioning Engine Administrator's Guide.

Hardware considerations

Hardware based RAID is preferred over Software based RAID due to its lower consumption of system resources. RAID 10 is the highest performing RAID implementation, and is recommended for the P4 database files.
The P4 database files, Versioned files, and P4 Journal file should all be located on separate physical disks, this maximized disk I/O performance.
The P4 database should not be hosted on NFS, NFS has relatively slow file locking performance and degrades overall system performance.

Distributed sites will tend to experience degraded performance accessing the central P4 Server. Consider using Server Replication to provide local service to remote sites. More information is here.

Build automation scripts can cause fragmentation of the perforce db.have table over time. This can be mitigated via using read-only clients. See the P4 Server Versioning Engine Administrator Guide: Fundamentals for more information.

P4 Submits and P4 Syncs between the server and client can be parallelized using the 'net.parallel.max' and associated configurables. More information can be found here.

'Tight Views' in which p4 clients are not configured with paths that include large amounts of unneeded data will improver server performance. Workspaces build with Perforce IPLM will use tight views by default.
Limiting users access via the protect table will also tend to increase performance, if a user is blocked from seeing an unnecessary section of the repository, resources will not be spent searching through that part of the repository.
The p4 typemap configuration can be used to prevent time spent compressing already compressed files. More information is here.
Using the Perforce IPLM Cache increases performance by not duplicating the p4 sync of read-only data. This data can be shared between users.

p4 reconcile, p4 status, and p4 clean support the '-m' option in perforce versions 2015.1 and later. This option allows the commands to look at the modification time of the relevant files rather than performing a costly computation for comparison purposes.

Large numbers of Perforce IPLM managed clients may degrade spec depot performance, more information on excluding them from the spec depot here.

Perforce autotune relies on the operating system's kernel to manage TCP buffer sizes, which has benefits when network latency is present. Autotune is enabled by default in P4 Server version 2019.1 and later, more details can be found here.

The storage footprint can be reduced and P4 Server performance increased by selecting a storage device that supports dedup (disk block storage c). This feature is often supported with SAN storage. You can also combine this with the lbr.autocompress perforce configuration setting, which will help the disk deduplication, and site to site replication. By enabling this, you can reduce perforce data compressions overhead, and still have to storage reduction benefits via dedup.