Deployment architecture

Small organizations often find a single server is adequate to meet user needs. However, as the business grows and usage expands in scale and geography, many organizations deploy a multi-server architecture.

To get a list of all the servers that are connected to this server, see p4 topology in the P4 CLI Reference.

Multi-server architectures

Architecture Advantage Disadvantage

Architecture	Advantage	Disadvantage
Commit-edge	Best performance overall because most commands are local. An edge server that is used only for automated processing, such as builds, can be deployed without a backup/recovery solution because the edge local data is critical only during build-time. The commit server has promoted shelves, the single source of truth for versioned files and metadata.	An edge server cannot be used as a standby server for the commit server, but an edge server can have its own standby server. Requires machine provisioning and administration, including backups of each edge (except in the case of a build edge server).
Distribution Server	Enhanced security because the commit server is “air gapped” from the Distribution Server.	Separate license is required for a Distribution Server.
Edge-to-edge chaining	Two or more edge servers can be chained together. If your organization is geographically dispersed, the configuration might allow all users to have an edge server nearby. Supports filtering. A Forwarding replica, with its `ReplicatingFrom` field correctly set, can be added to offload read-only commands.	The longer the chain, the longer it takes to complete replication. The outermost edge experiences the most latency.
Standby server	A standby or forwarding standby server provides a warm standby for the server it replicates. Standby servers support Failover from a commit-server (or standard) server in case it becomes unavailable. See Standby and forwarding-standby. You can also deploy a standby server to support failover from an edge server. See Standby for an edge.	Requires machine provisioning and administration.
Forwarding replica	Customizable filtering. Supports "daisy chaining" to additional sites, such as forwarding to a target server The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'. that forwards to the central server The one server that is innermost in a multi-server deployment. In the server specification form field for Services, the central server might be specified as “standard” or “commit-server”. If edge servers are part of the multi-server deployment, the central server must be a commit server. See also 'upstream server'.. Can reduce the metadata replication load on the central server and the amount of data traveling across the WAN. To learn more, see the Perforce Knowledge Base article on server-to-server arrangements, Helix replication rules.	"write" commands are slower because local metadata must be pulled from an upstream server Any server in the inward direction, that is, toward the central server. For example, in an edge-to-edge configuration with a commit, edge1, and edge2, both edge1 and the commit server are upstream servers for edge2. See also 'central server'.. Requires machine provisioning and administration. See Forwarding replica. Starting with 2018.2, we recommend a standby server with rpl.journalcopy.location=1 for high availability and disaster recovery.
P4 Broker	Supports allowing a command to pass, rejecting a command if the options are incorrect, redirecting a command to another server, filtering commands, and responding to a command. (See Command handler specifications) When the p4d process is offline for maintenance, the broker can display a user-friendly message.	Broker layer affects network performance. Forwarding replicas and edge servers are more recent technology and are an alternative to P4Broker redirection. See the Perforce Knowledge Base article, Using P4Broker to redirect read-only commands. Command triggers are an alternative to some traditional broker use cases. See Triggering before or after commands.
P4 Proxy	Easy to install, configure, and maintain. Improves performance by caching frequently transmitted file revisions. Reduces demand on P4 Server and the network over which it runs. No need to back up the proxy cache. Especially beneficial with larger files.	Not optimal for syncing large numbers of small files. A proxy cannot be deployed in front of a forwarding replica. See the Support Knowledgebase article on Proxy Performance.

Commit-edge

Best performance overall because most commands are local.

An edge server that is used only for automated processing, such as builds, can be deployed without a backup/recovery solution because the edge local data is critical only during build-time.

The commit server has promoted shelves, the single source of truth for versioned files and metadata.

An edge server cannot be used as a standby server for the commit server, but an edge server can have its own standby server.
Requires machine provisioning and administration,
including backups of each edge (except in the case of a build edge server).

Distribution Server

Enhanced security because the commit server is “air gapped” from the Distribution Server.

Separate license is required for a Distribution Server.

Edge-to-edge chaining

Two or more edge servers can be chained together.

If your organization is geographically dispersed, the configuration might allow all users to have an edge server nearby.

Supports filtering.

A Forwarding replica, with its ReplicatingFrom field correctly set, can be added to offload read-only commands.

The longer the chain, the longer it takes to complete replication.
The outermost edge experiences the most latency.

Standby server

A standby or forwarding standby server provides a warm standby for the server it replicates. Standby servers support Failover from a commit-server (or standard) server in case it becomes unavailable. See Standby and forwarding-standby.

You can also deploy a standby server to support failover from an edge server. See Standby for an edge.

Requires machine provisioning and administration.

Forwarding replica

Customizable filtering.

Supports "daisy chaining" to additional sites, such as forwarding to a target server The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'. that forwards to the central server The one server that is innermost in a multi-server deployment. In the server specification form field for Services, the central server might be specified as “standard” or “commit-server”. If edge servers are part of the multi-server deployment, the central server must be a commit server. See also 'upstream server'..

Can reduce the metadata replication load on the central server and the amount of data traveling across the WAN. To learn more, see the Perforce Knowledge Base article on server-to-server arrangements, Helix replication rules.

"write" commands are slower because local metadata must be pulled from an upstream server Any server in the inward direction, that is, toward the central server. For example, in an edge-to-edge configuration with a commit, edge1, and edge2, both edge1 and the commit server are upstream servers for edge2. See also 'central server'..
Requires machine provisioning and administration. See Forwarding replica.

Starting with 2018.2, we recommend a standby server with rpl.journalcopy.location=1 for high availability and disaster recovery.

P4 Broker

Supports allowing a command to pass, rejecting a command if the options are incorrect, redirecting a command to another server, filtering commands, and responding to a command. (See Command handler specifications)

When the p4d process is offline for maintenance, the broker can display a user-friendly message.

Broker layer affects network performance.
Forwarding replicas and edge servers are more recent technology and are an alternative to P4Broker redirection. See the Perforce Knowledge Base article, Using P4Broker to redirect read-only commands.
Command triggers are an alternative to some traditional broker use cases. See Triggering before or after commands.

P4 Proxy

Easy to install, configure, and maintain.

Improves performance by caching frequently transmitted file revisions.

Reduces demand on P4 Server and the network over which it runs.

No need to back up the proxy cache.

Especially beneficial with larger files.

Not optimal for syncing large numbers of small files.

A proxy cannot be deployed in front of a forwarding replica.
See the Support Knowledgebase article on Proxy Performance.

Services assignment

To assign a service to a server, the administrator uses the Services field that appears with the p4 server command. To learn more, see How server types handle requests.