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

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

    For more information, see the Knowledge Base 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 the Perforce service 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: