Preloading the cache directory for optimal initial performance

Helix Proxy stores file revisions only when one of its users submits a new revision to the depot or requests an existing revision from the depot. That is, file revisions are not prefetched. Performance gains from P4P occur only after file revisions are cached.

After starting P4P, you can prefetch the cache directory by creating a dedicated client workspace and syncing it to the head revision. All other users who subsequently connect to the proxy immediately obtain the performance improvements provided by P4P. For example, a development site located in Asia with a P4P server targeting a Helix Server in North America can preload its cache directory by using an automated job that runs a p4 sync against the entire Helix Server depot after most work at the North American site has been completed, but before its own developers arrive for work.

By default, p4 sync writes files to the client workspace. If you have a dedicated client workspace that you use to prefetch files for the proxy, however, this step is redundant. If this machine has slower I/O performance than the machine running the Helix Proxy, it can also be time-consuming.

To preload the proxy’s cache without the redundant step of also writing the files to the client workspace, use the -Zproxyload option when syncing. For example:

$ export P4CLIENT=prefetch
$ p4 sync //depot/main/written.txt
//depot/main/written.txt - refreshing /home/prefetch/main/written.txt
$ p4 -Zproxyload sync //depot/main/nonwritten.txt
//depot/main/nonwritten.txt - file(s) up-to-date.

Both files are now cached, but nonwritten.txt is never written to the the prefetch client workspace. When prefetching the entire depot, the time savings can be considerable.