Commit-edge

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

The commit-edge topology can provide performance benefits. Two examples:

• When the users are geographically near the edge server A server that is part of a commit-edge environment that can 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 P4 Server server in a topology with one or more edge servers..

• Reducing load on the commit server when the edge server handles commands prior to work being submitted.

P4 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 upstream 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 P4 Server replication technology. Before attempting to deploy a commit-edge configuration, read Replication overview, including the section on Connecting services, which includes information on Managing SSL/TLS 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 P4 Server commands behave differently when you have edge servers. To learn more, see the Support Perforce Knowledge Base article, Edge Servers.