Commit-edge

This topic assumes you have read the Guidelines for setting up multi-server services

Consider using the commit-edge architecture because it can provide excellent performance in many scenarios. For example, performance might improve when the users are geographically near the edge server A server that is part of a commit-edge environment that is able to independently support work in progress for locally-bound clients, thereby reducing the load on the commit server. but distant from the commit server The innermost Helix Core Server Server in a multi-server topology that implements the protocols required by Edge Servers..

Helix Core supports:

• Standby and forwarding-standby, where one server acts as a standby server for the commit server.

• Edge-to-edge chaining, which might be useful if your organization has more than two geographic locations.

• Standby for an edge, where one edge server act as a standby-edge server for its master-edge server.

The configuration of an edge server is defined on a commit server. A checkpoint of the commit server is then used to create the edge server. Regarding that checkpoint, see [-R service | -P server-id] -jd [-z] file.

Be aware of the following:

• The p4 unsubmit and p4 resubmit commands can be issued to a commit server, but not to an edge server.

• Commit-edge architecture builds upon Helix Core Server replication technology. Before attempting to deploy a commit-edge configuration, read Replication, including the section on Connecting services, which includes information on Managing SSL key pairs.

• An edge server can be used instead of a build server. If the only users of an edge server are build processes, disaster recovery is possible without backing up the local edge server-specific workspace and related information. See Migrating from existing installations.

• Some Helix Core Server commands behave differently when you have edge servers. To learn more, see the Support Perforce Knowledgebase article, Edge Servers.