Parallel processing for submits, syncs, and shelves
Parallel processing of submits, syncs, and shelves might aid performance for:
-
high-latency networks
-
network configurations that prevent a single TCP flow from making full use of available bandwidth
-
situations where the server transmits large compressed binary files to a multi-core client machine that uses parallel processing to uncompress the files
See also Parallel checkpointing, dumping and recovery.
The links that follow in this topic go to Helix Core Command-Line (P4) Reference.
The net.parallel.max
configurable specifies the maximum number of concurrent threads for p4 submit
, p4 sync
, and p4 shelve
Submit
To enable Parallel submits, specify the --parallel
option of the p4 submit
command.
To enable automatic parallel submits, set the
configurable to the number of
threads for sending files in parallel for each submit.net.parallel.submit.threads
Sync
To transfer files using multiple threads, specify the --parallel
option of the
command.p4 sync
To enable automatic parallel sync, set the net.parallel.threads
configurable on the server to a value greater than 1
, but less than or equal to the value of the
configurable.net.parallel.max
To reduce lock contention during parallel syncs, set the client.sendq.dir
configurable.
See Parallel processing for the p4 sync
command.
Shelves
To enable automatic parallel shelving, set the net.parallel.shelve.threads configurable to a value that is greater than 1
and less than or equal to the value of the
configurable. net.parallel.max
Optionally, set the:
-
net.parallel.shelve.min configurable to change the minimum number of files in a parallel shelve, which, by default, is
9
-
net.parallel.shelve.batch configurable to change the number of files in a batch for parallel shelving, which, by default, is
8
To disable automatic parallel shelving, unset the net.parallel.shelve.threads configurable.
Parallel processing in a commit-edge environment
Parallel submits can take place from an edge server to a commit server and the commit server can use standard pull threads to transfer the files. To enable this feature, the administrator makes sure that:
-
the commit server has a service user (see Types of users) that is logged in to the edge server
-
the tickets file of the service user is available to the commit server
-
the edge server external address is configured in its server spec. See the
p4 server
command.
-
If SSL is being used by the edge server, a trust is be set up between the commit and edge server, and the
P4TRUST
file is available to the commit server. See thep4 trust
command.
-
Promoted shelves require an additional file transfer from the edge server to the commit server. Parallel pull threads for this transfer require that the ExternalAddress field be set in the edge server spec and that pull threads can be used on the commit server. (This transfer using pull threads is not supported on Windows platforms.)
-
A user can override the shelve configurables on the command line or disable parallel shelving with the p4 shelve --parallel=0 command.