Perforce Public Knowledge Base - Setting Up a "Side-track" Server to Control Priority
Reset Search
 

 

Article

Setting Up a "Side-track" Server to Control Priority

« Go Back

Information

 
Problem
How do I set up a "side-track" server to give lower priority to build servers?

During peak hours at large sites, the combination of high command volume and commands run against large data-sets can drive up Perforce server memory requirements. The visible results include paging at the server machine and slow command response at the client machine.

To give priority to interactive user commands, the Perforce administrator can set up a "side-track" server to handle non-priority commands in series. This reduces the concurrent commands the server has to deal with, improving response time of commands issued against the main server.
Solution

The side-track server listens on a separate P4PORT. Instead of forking concurrent processes for each request, it handles each request in turn. Batch scripts can use the side-track server because the slower command response time will not be an inconvenience to them.

For example, say the main Perforce server runs on P4PORT "computer:1666". On the same machine, one can then start up a side-track server on P4PORT "computer:1667" with this command:
 
p4d -p computer:1667 -f 

The -f flag is what keeps the side-track server from forking concurrent processes. (Be sure all other Perforce server configuration variables, including P4PORT, are set the same as the main server settings, or include them on the p4d command line.)

Note: The -f flag is only needed if it helps diagnotics by keeping all activity on a single thread.  If, for example you have a non-SSL server and an SSL both running, you do not need the -f flag.

Users wishing to run a large command through the side-track server can simply set their P4PORT to "computer:1667", or use the "-p computer:1667" flag on the p4 commands. Batch scripts can be configured to always run with P4PORT=computer:1667.

To clarify, the side-track server operates against the main Perforce database files. In other words, the side-track server shares the same Perforce server root (P4ROOT) and the same journal file. If the side-track server used a different P4ROOT location, it would be a different server entirely.

Similarly, if a separate journal location was specified for the side-track server, then two journal files would exist, each recording different transactions against the same server. However, only the journal file associated with the main server is ever truncated in a checkpoint operation of the main server. Although the resultant checkpoint will be complete, the associated journal file will not be (it will be missing whatever was recorded in the other journal). Whichever journal was not truncated will continue to grow. Therefore, do not attempt to specify a separate journal file location when configuring and starting a side-track server.  Using a separate log file for recording errors from the side-track server can be useful for diagnostic purposes.

The side-track server should pick up the P4ROOT and P4JOURNAL environment variable values from the main Perforce server. Log entries for it can be sent to either the main Perforce 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, one can redirect requests on-the-fly to the side-track server by using the global -p flag with p4 commands to change the Perforce port setting for that command. For example:
 

 
p4 -p computer:1667 diff -se

For details on the Perforce global options, see the appropriate section of the Perforce Command Reference or the output of "p4 help usage".
 

Additional considerations:

In general, there will only be a performance benefit when there are actually batch requests re-routed to the side-track server. That is, the side-track server will process 10 requests, one at at time, instead of processing 10 requests all at once. The reason the side-track server does not provide any benefit for single commands is because it effectively operates like just another p4d process and encounters the same bottlenecks as the main server when locking the db files and writing to the journal.

The primary uses of the side-track server are to present batch requests in series, and to perform diagnostics on server operations. Because side-track server requests can be separately logged, problem client requests can be redirected to the side-track server port and the output logs can be analyzed by Perforce Support.


Single threading for diagnostics

Another use of the -f flag is to help diagnose a difficult network problem involving Perforce.  It might be useful to look at the client/server protocol output using the rpc=3 flag to see exactly where and how communication is being interrupted, without causing the main server log file to grow excessively due to the detailed logging of RPC messages. The debugging flag output goes to STDOUT and can be redirected to a file, like this:
 
p4d -v rpc=3 -p 1667 -L p4sidetrack.log 1 > p4debug.1667

 
Related Links

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255