Perforce is built to handle distributed development in a wide range of network topologies. Where bandwidth to remote sites is limited, P4P, the Perforce Proxy, improves performance by mediating between Perforce clients and servers to cache frequently transmitted file revisions. By intercepting requests for cached file revisions, P4P reduces demand on the Perforce server and network.
To improve performance obtained by multiple Perforce clients accessing a central Perforce server across a WAN, configure P4P on the side of the network close to the clients and configure the clients to access P4P; then configure P4P to access the central Perforce server. (On a LAN, you can also obtain performance improvements by setting up proxies to divert workload from the central server's CPU and disks.)
In this configuration, file revisions requested by users at a remote development site are fetched first from a central Perforce server (
p4d running on
central) and transferred over a relatively slow WAN. Subsequent requests for that same revision, however, are delivered from the Perforce Proxy, (
p4p running on
outpost), over the remote development site's LAN, reducing both network traffic across the WAN and CPU load on the central server.
|
1.
|
Download the p4p executable to the machine on which you want to run the proxy.
|
|
3.
|
Select a port (P4PORT) on which p4p will listen for requests from Perforce client programs.
|
To run P4P, invoke the p4p executable, configuring it with environment variables or command-line flags. Flags you specify on the command line override environment variable settings.
To use the proxy, Perforce client programs connect to P4P on port 1999 on the machine where the proxy runs. P4P file revisions are stored under a directory named
/var/proxyroot.
To pass parameters to the P4Proxy service, set the P4POPTIONS registry variable using the
p4 set command. For example, if you normally run the Proxy with the command:
you can set the P4POPTIONS variable for a Windows service named
Perforce Proxy by setting the service parameters as follows:
p4 set -S "Perforce Proxy" P4POPTIONS="-p 1999 -t mainserver:1666"
When you run P4P under the "Perforce Proxy" service, the Proxy will listen to port 1999 and communicate with the Perforce Server at
mainserver:1666.
P4P is effectively stateless; to stop P4P under UNIX, kill the
p4p process with
SIGTERM or
SIGKILL. Under Windows, click in the .
P4P caches file revisions in its cache directory. These revisions accumulate until you delete them. P4P does not delete its cached files or otherwise manage its consumption of disk space.
For example, if a Perforce server is running on central:1666 and you direct your Perforce client to a Perforce Proxy running on
outpost:1999, the output of
p4 info resembles the following:
User name: p4admClient name: admin-temp Client host: remotesite22 Client root: /home/p4adm/tmp Current directory: /home/p4adm/tmp Client address: 192.168.0.123:55768 Server address: central:1666 Server root: /usr/depot/p4d Server date: 2008/06/28 15:03:05 -0700 PDT Server uptime: 752:41:23 Server version: P4D/FREEBSD4/2008.1/156375 (2008/05/25) Proxy version: P4P/SOLARIS26/2008.1/156884 (2008/05/25) Server license: P4 Admin <p4adm> 20 users (expires 2009/01/01) Server license-ip: 10.0.0.2
|
For instance, consider an organization with a remote development site with workstations on a subnet of
192.168.10.0/24. The organization also has a central office where local development takes place; the central office exists on the
10.0.0.0/8 subnet. A Perforce server resides on the
10.0.0.0/8 subnet, and a Perforce Proxy resides on the
192.168.10.0/24 subnet. Users at the remote site belong to the group
remotedev, and occasionally visit the central office.
To ensure that members of the remotedev group use the proxy while working at the remote site, but do not use the proxy when visiting the local site, add the following lines to your protections table:
list group remotedev 192.168.10.0/24 -//... write group remotedev proxy-192.168.10.0/24 //... list group remotedev proxy-10.0.0.0/8 -//... write group remotedev 10.0.0.0/8 //...
|
The first line denies list access to all users in the
remotedev group if they attempt to access Perforce without using the proxy from their workstations in the
192.168.10.0/24 subnet. The second line grants write access to all users in
remotedev if they are using a Perforce Proxy server and are working from the
192.168.10.0/24 subnet. Users of workstations at the remote site must use the proxy.
Similarly, the third and fourth lines deny list access to
remotedev users when they attempt to use the proxy from workstations on the central office's subnet (
10.0.0.0/8), but grant write access to
remotedev users who access the Perforce server directly from workstations on the central office's subnet. When visiting the local site, users from the
remotedev group must access the Perforce server directly.
Use the -Zproxyverbose flag with
p4 to display messages indicating whether file revisions are coming from the proxy (
p4p) or the central server (
p4d).
To disable compression, specify the -c option when you invoke
p4p. This option is particularly effective if you have excess network and disk capacity and are storing large numbers of binary file revisions in the depot, because the proxy (rather than the server) decompresses the binary files from its cache before sending them to Perforce clients.
If network bandwidth on the same subnet as the central Perforce server is nearly saturated, deploying proxy servers on the same subnet will not likely result in a performance improvement. Instead, deploy the proxy servers on the other side of a router so that the traffic from the clients to the proxy server is isolated to a subnet separate from the subnet containing the central Perforce server.
Deploying an additional proxy server on a subnet when network bandwidth on the subnet is nearly saturated will not likely result in a performance improvement. Instead, split the subnet into multiple subnets and deploy a proxy server in each resulting subnet.
In the illustrated configuration, a server room houses a company's Perforce server (p4d), a network storage device (NAS), and a database server (RDBMS). The server room's network segment is saturated by heavy loads placed on it by a sales force constantly querying a database for live updates, and by developers and graphic artists frequently accessing large files through the Perforce server.
Deploying two instances of Perforce Proxy (one on the developers' subnet, and one on the graphic artists' subnet) enables all three groups to benefit from improved performance due to decreased use on the server room's network segment.
P4P stores file revisions only when one of its clients 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 effectively prefetch the cache directory by creating a dedicated client workspace and syncing it to the head revision. All other clients that 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 Perforce server in North America can preload its cache directory by using an automated job that runs a
p4 sync against the entire Perforce 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 the client machine has slower I/O performance than the machine running the Perforce Proxy, it can also be time-consuming.
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.
P4P stores revisions as if there were only one depot tree. If this approach stores too much file data onto one filesystem, you can use symbolic links to spread the revisions across multiple filesystems.
For instance, if the P4P cache root is /disk1/proxy, and the Perforce server it supports has two depots named
//depot and
//released, you can split data across disks, storing
//depot on
disk1 and
//released on
disk2 as follows:
The symbolic link means that when P4P attempts to cache files in the //released depot to
/disk1/proxy/released, the files are stored on
/disk2/proxy/released.
Copyright 1997-2009 Perforce Software.
