The Helix Core Proxy Server is a free caching server that can be deployed to accelerate file access operations between locations with limited network resources. When a user performs a sync to their local machine, or a submit to the Helix Core server, the proxy caches the repository files at the remote office so they don't have to be transferred to and from the central server on every operation.
Deploying and operating a Helix Core proxy is simple. The first step is to choose a machine in your remote office on which you will run the proxy. The proxy CPU and memory don’t need to be any larger than the production machine. In fact, you can often use less capable machines at smaller remote locations. The primary resource that a proxy requires is disk space, so make sure your chosen machine has a comfortable amount.
You can download the latest p4p proxy software from the Perforce web site, or from the FTP site onto your chosen machine. If you don’t have the p4 command-line client handy, you can download that as well.
Generally, you'll want the proxy to be always in service, and typically this means setting up an /etc/init.d script with the appropriate command to run the proxy. On a Windows server, the proxy should be run as a Windows Service.
Now we need to make a few decisions about how to configure the proxy. In this example, we will deploy on a Linux server. First, let’s make a directory where the proxy can store its cache of repository files. Make sure that directory exists, and is readable and writable by the userid that will run the proxy. No other permissions configuration is required.
Next, let’s issue the command to startup the proxy. We start by declaring the directory where the files will be cached. We also need to decide which userid to use, and which port number the proxy should listen on. If your main Perforce server listens on P4PORT 1666, you might specify that your proxy listens on the same port number.
Lastly, when installing a new proxy, it is also useful to enable proxy monitoring, and to define a proxy log file, so your full proxy configuration should look something this. Next, test your proxy to make sure it's working.
A Helix Core proxy needs almost no regular attention. If you want to keep an eye on what it is doing, you can view the monitoring display by running 'p4p -m3' on the proxy machine. Here, we see someone is modifying their client spec.
The one thing you must do is periodically check on the amount of disk space on your proxy machine. If it is nearly full, you should either add more disk space, or you can remove unused files that are currently stored in the proxy's cache.
If you have multiple remote offices, you can install multiple proxies. You can have as many proxies as you want, but generally there is no need for more than one proxy at a single location, since the proxy can serve hundreds of users simultaneously.
The Helix Core proxy is not a replication server so it does not hold or modify any metadata related to the files. It simply stores file versions for faster retrieval. As such, it does not need to be backed up. If there is a failure, the files will still be available via the central server. A new proxy can be dropped in and it will populate the cache again as users sync and submit.
That's it, you're done! Your proxy is up and running. To use the proxy, your remote office users simply need to change their connection address from central server to proxy