Using proxies to improve performance

To improve performance for users accessing a shared Helix Server repository across a WAN, you can configure a proxy on the side of the network close to the users and configure the users to access the service through the proxy; then configure the proxy to access the master Helix Server service.

The following diagram illustrates a typical proxy configuration:

In this configuration, file revisions requested by users at a remote development site are fetched first from a shared server (p4d running on Central) and transferred over a relatively slow WAN. Subsequent requests for that same revision, however, are delivered from the Helix Proxy, (p4p running on Outpost), over the remote development site’s LAN; this architecture reduces both network traffic across the WAN and CPU load on the shared server.

Using a replica for disaster recovery

Replication is the duplication of server data from one Helix Server to another. The replicated server is called the master server. Its replica is called a replica server.

You can use replication to provide a warm standby server to aid in disaster recovery, or to reduce load and downtime on a primary server when performing builds.

When you create the replica, you specify which server it should get its data from. The replica then periodically updates itself by copying files and metadata from the master. If the master fails, all you need do is reconfigure the replica to be the new master and then reconnect clients to communicate with it.

Edge servers and workspace servers, described in the following sections, are special examples of replica servers.