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.

Tip

To get a list of all the servers that are connected to this server, see p4 topology in the Helix Core Command-Line (P4) Reference.

Multi-server architectures

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.
  • Cannot be used as a standby.
  • 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 required for a Distribution Server.

Edge-to-edge chaining

  • Edge servers can be chained together.
  • If your organization is geographically dispersed, the configuration might allow all users to have an edge server nearby.
  • 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 (or master) 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. For example, a site in the Philippines might forward to a site in Taiwan that forwards to a site in Japan that forwards to the Master in France. This alternative to directly connecting each Asian site to Europe:
    • reduces the metadata replication load on the master server
    • reduces the amount of data traveling across the WAN from Europe to Asia

    To learn more, see the Perforce Knowledgebase article on server-to-server arrangements, Helix replication rules.
  • "write" commands are slower because local metadata must be pulled from the master.
  • Requires machine provisioning and administration. See Forwarding replica.
Tip

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

Helix Broker

  • Supports the following: allow a command to pass, reject a command (for example, if the options are incorrect), redirect a command to another server, filter commands, respond to a command. (See Command handler specifications)
  • When the p4d process is offline for maintenance, the broker can display a message such as "This server is undergoing maintenance", which is more user-friendly than a TCP connect error.
Tip

Note that during the Failover process, such a message is visible to the end-users without using a broker.
     

Helix Proxy

  • Easy to install, configure, and maintain.

  • Improves performance by caching frequently transmitted file revisions.

  • Reduces demand on Helix Core 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.

Tip
  • A proxy cannot be deployed in front of a forwarding replica.
  • See the Support Knowledgbase 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:

Tip

For additional details, see: