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 Migrate from existing installations.

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