Other considerations

As you deploy Edge Servers, give consideration to the following areas.

  • Labels

    In a distributed Perforce service, labels can be local to an Edge Server or global.

    • By default, labels are also bound to the Edge Server on which they are created.
    • The -g flag defaults to the value of 0, which indicates that the label is to be defined globally on all servers in the installation. Configuring rpl.labels.global=1 allows updating of local labels. See rpl.labels.global in the P4 Command Reference.
    • For important details, on the command line, type p4 help distributed.

  • Exclusive Opens

    Exclusive opens (+l filetype modifier) are global: establishing an exclusive open requires communication with the Commit Server, which might incur network latency.

  • Integrations with third party tools

    If you integrate third party tools, such as defect trackers, with Helix Core Server, evaluate whether those tools should continue to connect to the master/Commit Server or could use an Edge Server instead. If the tools only access global data, then they can connect at any point. If they reference information local to an Edge Server, like workspace data, then they must connect to specific Edge Servers.

    Build processes can usefully be connected to a dedicated Edge Server, providing full Helix Core Server functionality while isolating build workspace metadata. Using an Edge Server in this way is similar to using a build server, but with the additional flexibility of being able to run write commands as part of the build process.

  • Files with propagating attributes

    In distributed environments, the following commands are not supported for files with propagating attributes: p4 copy, p4 delete, p4 edit, p4 integrate, p4 reconcile, p4 resolve, p4 shelve, p4 submit, and p4 unshelve. Integration of files with propagating attributes from an Edge Server is not supported. Depending on the integration action, target, and source, either the p4 integrate or the p4 resolve command will fail.

    If your site makes use of this feature, direct these commands to the Commit Server, not the Edge Server. Perforce-supplied software does not presently set propagating attributes on files and is not known to be affected by this limitation.

  • Logging and auditing

    Edge Servers maintain their own set of server and audit logs. Consider using structured logs for Edge Servers, as they auto-rotate and clean up with journal rotations. Incorporate each Edge Server’s logs into your overall monitoring and auditing system.

    In particular, consider the use of the rpl.checksum.* configurables to automatically verify database tables for consistency during journal rotation, changelist submission, and table scans and unloads. Regularly monitor the integrity.csv structured log for integrity events.

  • Unload depot

    The unload depot might have different contents on each Edge Server. Clients and labels bound to an Edge Server are unloaded into the unload depot on that Edge Server, and are not displayed by the p4 clients -U and p4 labels -U commands on other Edge Servers.

    Be sure to include the unload depot as part of your Edge Server backups. The Commit Server does not verify that the unload depot is empty on every Edge Server. Therefore, to delete the unload depot from the Commit Server, p4 depot -d -f is the command.

  • Future upgrades

    Commit and Edge Servers should be upgraded at the same time.

  • Time zones

    Commit and Edge Servers must use the same time zone.

  • Helix Swarm

    For details about Helix Swarm support for possible configurations of a Helix Core server, see Swarm configuration in the Helix Swarm Guide.