Prevent server swamp

Generally, the performance of P4 Server depends on the number of files a user tries to manipulate in a single command invocation, not on the size of the depot. That is, syncing a client view of 30 files from a 3,000,000-file depot should not be much slower than syncing a client view of 30 files from a 30-file depot.

The number of files affected by a single command is largely determined by the following factors:

• p4 command-line arguments (or selected folders in the case of GUI operations)

  Without arguments, most commands operate on, or at least refer to, all files in the client workspace view.

• Client views, branch views, label views, and protections

  Because commands without arguments operate on all files in the workspace view, it follows that the use of unrestricted views and unlimited protections can result in commands operating on all files in the depot.

When the server answers a request, it locks down the database for the duration of the computation phase. For normal operations, this is a successful strategy, because the server can "get in and out" quickly enough to avoid a backlog of requests. Abnormally large requests, however, can take seconds, sometimes even minutes. If frustrated users press CTRL+C and retry, the problem gets even worse because the server consumes more memory and responds even more slowly.

Consider the following:

• If you must use the p4 obliterate command, it is best to do so during off hours. This command locks the entire database while it scans the entire database repeatedly, once for each file argument.

• Sites with large depots should avoid unrestricted views and unqualified commands.

• The System resources section explains how to regulate the amount of work the P4 Server accepts when resources become limited.

To learn how to prevent server swamp, read the pages in this section: