The 2013.2 Perforce release introduces two new modes of operation for a Perforce service:

The combination of a commit server and one or more edge servers is called a distributed Perforce service.

Since an edge server can handle most routine operations locally, a distributed Perforce service offloads a significant amount of processing work from the commit server and reduces data transmission between commit and edge servers.

From a user's perspective, most typical operations until the point of submit are handled by an edge server. With a forwarding replica, read operations, such as obtaining a list of files or viewing file history, are local. But with an edge server, syncing, checking out, merging, resolving, and reverting files are all local operations.

A distributed Perforce service offers significant performance improvements in certain scenarios. All scenarios require additional management.

You can deploy commit and edge servers incrementally. An existing master server may be reconfigured to act as a commit server, and serve in hybrid mode. The commit server continues to service all existing users, workspaces, proxies, and replicas with no change in behavior. The only immediate difference is that the commit server can now support edge servers.

Once a commit server is available, you can proceed to configure one or more edge servers. Deploying a single edge server for a pilot team is a good way to become familiar with edge server behavior and configuration.

Additional edge servers can be deployed periodically, giving you time to adjust any affected processes and educate users about any changes to their workflow.

Initially, running a commit server and edge server on the same machine can help achieve a full split of operations, which can make subsequent edge server deployments easier.

For an initial deployment of a distributed Perforce service, where the commit server acts in a hybrid mode, the commit server uses your current master server hardware. Over time you may see the performance load on the commit server drop as you add more edge servers. You can reevaluate commit server hardware sizing after the first year of operation.

An edge server handles a significant amount of work for users connected to that edge server. A sensible strategy is to repurpose an existing forwarding replica and monitor the performance load on that hardware. Repurposing a forwarding replica involves:

As you deploy more edge servers, you have the flexibility to deploy a smaller number of edge servers with more powerful hardware, or a larger number of edge servers each using less powerful hardware to service a smaller number of users.

You can also take advantage of replication filtering to reduce the volume of metadata and archive content on an edge server.

Filtering edge server content can reduce the demands for storage and performance capacity.

As you transition to a distributed Perforce service and the commit server is only handling requests from edge servers, you may find that an edge server requires more hardware resources than the commit server.

A commit server can use the same backup and HA/DR strategy as a master server. Edge servers contain unique information and should have a backup and HA/DR plan. Whether an edge server outage is as urgent as a master server outage depends on your requirements. Therefore, an edge server may have an HA/DR plan with a less ambitious Recovery Point Objective (RPO) and Recovery Time Objective (RTO) than the commit server.

If a commit server must be rebuilt from backups, each edge server must be rolled back to a backup prior to the commit server's backup. Alternatively, if your commit server has no local users, the commit server can be rebuilt from a fully-replicated edge server (in this scenario, the edge server is a superset of the commit server).

Backing up and recovering an edge server is similar to backing up and restoring a standard Perforce server. As long as the edge server's replication state file is included in the backup, the edge server can be restored and resume service. If the edge server was offline for a long period of time, it may need some time to catch up on the activity on the commit server.

As part of a failover plan for a commit server, make sure that the edge servers are redirected to use the new commit server.

If you currently use Perforce proxies, evaluate whether these should be replaced with edge servers. If a proxy is delivering acceptable performance then it can be left in place indefinitely. You can use proxies in front of edge servers if necessary. Deploying commit and edge servers is notably more complex than a master server and proxy servers. Consider your environment carefully.

Of the three types of replicas available, forwarding replicas are the best candidates to be replaced with edge servers. An edge server provides a better solution than a forwarding replica for many use cases.

Build replicas can be replaced if necessary. If your build processes need to issue write commands other than p4 sync, an edge server is a good option. But if your build replicas are serving adequately, then you can continue to use them indefinitely.

Read-only replicas, typically used for disaster recovery, can remain in place. You can use read-only replicas as part of a backup plan for edge servers.

As you create new edge servers, you assign some users and groups to use that edge server.

The 2014.1 Perforce release allows changelists shelved on an edge server, which would normally be inaccessible from other edge servers, to be promoted to the commit server. Promoted shelved changelists are available to any edge server.

Promotion occurs when shelving a changelist by using the -p flag with the p4 shelve command.

For example, given two edge servers, edge1 and edge2, the process works as follows:

As you deploy edge servers, give consideration to the following areas.

As you deploy commit and edge servers, you can focus your testing and validation efforts in the following areas.

In a distributed Perforce service, triggers might run either on the commit server, or on the edge server, or perhaps on both. For more information on triggers, see the Perforce System Administrator's Guide.

Trigger scripts can determine whether they are running on a commit or edge server using the following trigger variables:

When a trigger is executed on the commit server, %peerip% will match %clientip%.

For more information on trigger variables, see the Perforce System Administrator's Guide.

@echo off
rem REMINDERS
rem - If necessary, set Perforce environment vars or use config file
rem - Set PATH or use full paths (C:\PROGRA~1\Perforce\p4.exe)
rem - Use short pathnames for paths with spaces, or quotes
rem - For troubleshooting, log output to file, for instance:
rem - C:\PROGRA~1\Perforce\p4 info >> trigger.log
if not x%1==x goto doit
echo Usage is %0[change#]
:doit
p4 describe -s %1|findstr "Review Approved...\n\n\t" > nul
if errorlevel 1 echo Your code has not been revewed for changelist %1
p4 describe -s %1|findstr "Review Approved...\n\n\t" > nul

sampleEdge   edge-submit //depot/qa/...   "reviewcheck.bat %changelist%"