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.

Note

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 net.parallel.submit.threads configurable to the number of threads for sending files in parallel for each submit.

Sync

To transfer files using multiple threads, specify the --parallel option of the p4 sync command.

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 net.parallel.max configurable.

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 net.parallel.max configurable.

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 the p4 trust command.

Note
  • 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.