Side-tracking builds to prioritize interactive commands
During peak hours at large sites, the combination of high command volume and commands run against large data sets can increase the load on server memory. This might cause paging at the server machine and slow command response at the client machine.
To give priority to interactive user commands on the main server port, you can set up a separate port on the same machine that handles low priority commands one at a time. This reduces the load of concurrent commands on the main server port.
Thus a single server with two ports acts almost as if it were two servers, the main server for immediate interaction, and the "side-track" server for builds or batches where a slower command response might not matter.
Do not expect the side-track server to provide any benefit for single commands because it encounters the same bottlenecks as the main server when locking the database files and writing to the journal.
Side-track server port
The side-track server:
-
listens on a P4PORT that is separate from the main P4PORT.
-
handles each request one-by-one
Example of two ports on one server
Suppose the main Perforce server runs on computer:1666 as its P4PORT.
On the same machine, you can then start up a side-track server that uses computer:1667 as its P4PORT by issuing the command:
p4d -p computer:1667 -f
The -f flag causes the side-track server to run as a single-threaded process. See Server options.
Make sure that all the other server configuration variables are set the same as the main server settings, or include them on the p4d command line.
Using for batches and builds
Users who want to run a large command, such as a large build, through the side-track server can set their P4PORT to computer:1667 or use the -p computer:1667 option on the p4 command line. Batch scripts can be configured to run with P4PORT=computer:1667 so they avoid the main server.
The side-track server operates against the main Perforce database files. In other words, the side-track server shares the same Helix ServerP4ROOT and the same journal file.
The side-track server get its P4ROOT and P4JOURNAL environment variable values from the main server. Log entries for it can be sent to either the main server log (P4LOG) or to a separate log file, by specifying it in the side-track server command invocation. For example:
p4d -p computer:1667 -f -L p4sidetrack.log
On the client side, a user can redirect requests on-the-fly to the side-track server by using the global -p option with p4 commands to change the server port setting for that command. For example:
p4 -p computer:1667 diff -se
For details, see Global options in Helix Core Command-Line (P4) Reference.
Using for diagnostic logging
Using a separate log file for recording errors from the side-track server can be useful for diagnostic purposes. This is a way to avoid causing the main server log file to grow excessively.
For example, detailed logging of RPC messages can grow large. It might be useful to look at the client/server protocol output using the rpc=3 flag to see how communication is being interrupted. The debugging flag output that goes to STDOUT can be redirected to a file:
p4d -v rpc=3 -p 1667 -L p4sidetrack.log 1 > p4debug.1667
The side-tracker server can aid diagnostics by having all the activity it logs be on a single thread. However, if you have a non-SSL server and an SSL both running, you do not have a single thread.