Perforce Public Knowledge Base - Distributed Perforce Service
Reset Search
 

 

Article

Distributed Perforce Service

« Go Back

Information

 
Problem
How can I improve performance in geographically distributed environments?
 
Solution
The basics of a distributed Helix Versioning Engine installation are covered in the Multi-Site Deployment Guide guide. This article provides a summary of those basics with references to more detailed documentation. A distributed Helix Versioning Engine installation builds upon Perforce Replication technology. Read and understand the chapter on Perforce Replication in the Multi-Site Deployment Guide before deploying a distributed installation.

Commit and Edge Servers

A commit server stores the canonical archives and permanent metadata. In working terms, it is similar to a Perforce master server, but may not contain all workspace information.

An edge server contains a replicated copy of the commit server data and a unique, local copy of some workspace and work-in-progress information. In working terms, it is similar to a forwarding replica, but contains local workspace data and can handle more operations with no reliance on the commit server.

A distributed Helix service consists of a combination of a commit server and one or more edge servers. 



kA0F0000000CqjrKAC_en_US_4_0


Since an edge server can handle most routine operations locally, a distributed Helix service offloads a significant amount of processing work from the commit server and reduces data transmission between commit and edge servers. For more details on behaviors of edge servers, see the following Knowledge Base article. 

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. With an edge server, syncing, checking out, merging, resolving, and reverting files are all local operations on the edge server.

Deploying commit and edge servers can be done incrementally. An existing master server may be configured to act as a commit server. The commit server continues to service existing users, workspaces, proxies, and replicas with no change in behavior. The only immediate difference is 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 change to their workflow.

 

Related Links

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255