Prevent Server swamp
Generally, the performance of Helix Core 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.
The p4 obliterate command scans the entire database once per file argument and locks the entire database while scanning. It is best to do this during off hours for large sites.
To learn how to regulate the amount of work the Server accepts when resources become limited, see System resources.
At sites with very large depots, unrestricted views and unqualified commands are not optimal. Users and administrators can reduce the load on their Servers:
