Perforce can run over any TCP/IP network. For remote users or distributed configurations, Perforce offers options like proxies and the commit/edge architecture that can enhance performance over a WAN. Compression in the network layer can also help. For additional information about network and performance tuning, see “Tuning Perforce for Performance”.

CPU resource consumption can be adversely affected by compression, lockless reads, or a badly designed protections table. In general, there is a trade-off between speed and the number of cores. A minimum of 2.4 GHZ and 8 cores is recommended. With greater speed, fewer cores will do: for example, a 3.2 GHZ and 4-core processor will also work.

For additional details, see CPU.

There are a couple of guidelines you can follow to anticipate memory needs:

In general Perforce performs well on machines that have large memory footprints that can be used for file system cache. I/O to even the fastest disk will be slower than reading from the file cache. These guidelines only apply for a single server.

For additional information about memory and performance tuning, see “Tuning Perforce for Performance”.

Perforce disk space usage is a function of three variables:

All three variables depend on the nature of your data and how heavily you use Perforce.

The client file space required is the size of the files that your users will need in their client workspaces at any one time.

The server’s database size can be calculated with a fair level of accuracy; as a rough estimate, it requires 0.5 kilobytes per user per file. (For instance, a system with 10,000 files and 50 users requires 250 MB of disk space for the database). The database can be expected to grow over time as histories of the individual files grow.

The size of the server’s archive of versioned files depends on the sizes of the original files stored and grows as revisions are added. A good guideline is to allocate sufficient space in your P4ROOT directory to hold three times the size of your users' present collection of versioned files, plus an additional 0.5KB per user per file to hold the database files that store the list of depot files, file status, and file revision histories.

The db.have file holds the list of files opened in client workspaces. This file tends to grow more rapidly than other files in the database. If you are experiencing issues related to the size of your db.have file and are unable to quickly switch to a server with adequate support for large files, deleting unused client workspace specifications and reducing the scope of client workspace views can help alleviate the problem.

File size and disk I/O are the key issues here. For more information, see File systems.

Until you define a Perforce superuser, every Perforce user is a Perforce superuser and can run any Perforce command on any file. After you start a new Perforce service, use:

$ p4 protect

as soon as possible to define a Perforce superuser. To learn more about how p4 protect works, see Authorizing access.

Without passwords, any user is able to impersonate any other Perforce user, either with the -u flag or by setting P4USER to an existing Perforce user name. Use of Perforce passwords prevents such impersonation. See the Helix Versioning Engine User Guide for details.

To set (or reset) a user’s password, either use p4 passwd username (as a Perforce superuser), and enter the new password for the user, or invoke p4 user -f username (also while as a Perforce superuser) and enter the new password into the user specification form.

The security-conscious Perforce superuser also uses p4 protect to ensure that no access higher than list is granted to unprivileged users, p4 configure to set the security level to a level that requires that all users have strong passwords, and p4 group to assign all users to groups (and, optionally, to require regular changes of passwords for users on a per-group basis, to set a minimum required password length for all users on the site, and to lock out users for predefined amounts of time after repeated failed login attempts).

$ p4d localhost:2019

For complete information about security, see “Securing the Server”.

After the helix-p4d package has been installed, additional configuration is required. Perform the following steps:

On UNIX (or Mac OS X), you must make the p4 and p4d binaries executable. After you download the software, use the chmod command to make them executable, as follows:

$ chmod +x p4
$ chmod +x p4d

The Perforce service stores all user-submitted files and system-generated metadata in files and subdirectories beneath its own root directory. This directory is called the server root.

To specify a server root, either set the environment variable P4ROOT to point to the server root, or use the -r server_root flag when invoking p4d. Perforce applications never use the P4ROOT directory or environment variable; p4d is the only process that uses the P4ROOT variable.

Because all Perforce files are stored by default beneath the server root, the contents of the server root can grow over time. See Disk space allocation for information about diskspace requirements.

The Perforce service requires no privileged access; there is no need to run p4d as root or any other privileged user. For more information, see Running p4d as an unprivileged user.

The server root can be located anywhere, but the account that runs p4d must have read, write, and execute permissions on the server root and all directories beneath it. For security purposes, set the umask(1) file-creation-mode mask of the account that runs p4d to a value that denies other users access to the server root directory.

The p4d service and Perforce applications communicate with each other using TCP/IP. When p4d starts, it listens (by default) for plaintext connections on port 1666. Perforce applications like p4 assume (also by default) that the corresponding p4d is located on a host named perforce, listening on port 1666, and that communications are performed in plaintext.

If p4d is to listen on a different host or port and/or use a different protocol, either specify the configuration with the -p protocol:host:port flag when you start p4d (as in, p4d -p ssl:perforce:1818), or by the contents of the P4PORT environment variable.

Plaintext communications are specified with tcp:host:port and SSL encryption is specified with ssl:port. (To use SSL, you must also supply or generate an x509 certificate and private key, and store them in a secure location on your server. See Using SSL to encrypt connections to a Perforce server for details.)

The preferred syntax for specifying the port is the following:

protocol:host:port

There are situations, for example if you are using multiple network cards, where you might want to specify the port on which to listen using syntax like the following:

P4PORT=ssl::1666

The use of the double colon directs the server to bind to all available network addresses and to listen on port 1666. This can be useful if the host has multiple network addresses.

$ p4d -p tcp64:[::]:1818

$ p4d -p ssl64:[::]:1818

$ p4d -p ssl6:[::]:1818

Unlike P4ROOT, the environment variable P4PORT is used by both the Perforce service and the Perforce applications, so it must be set both on the machine that hosts the Perforce service and on individual user workstations.

Perforce applications need to know on what machine the p4d service is listening, on which TCP/IP port p4d is listening, and whether to communicate in plaintext or over SSL.

Set each Perforce user’s P4PORT environment variable to protocol:host:port, where protocol is the communications protocol (beginning with ssl: for SSL, or tcp: for plaintext), host is the name of the machine on which p4d is running, and port is the number of the port on which p4d is listening. For example:

If you have enabled SSL, users are shown the server’s fingerprint the first time they attempt to connect to the service. If the fingerprint is accurate, users can use the p4 trust command (either p4 trust -y, or p4 -p ssl:host:port trust -i fingerprint) to install the fingerprint into a file (pointed to by the P4TRUST environment variable) that holds a list of known/trusted Perforce servers and their respective fingerprints. If P4TRUST is unset, this file is .p4trust in the user’s home directory.

As of Release 2013.1, Perforce supports connectivity over IPv6 networks as well as over IPv4 networks.

Behavior and performance of networked services is contingent not merely upon the networking capabilities of the machine that hosts the service, nor only on the operating systems used by the end users, but also on your specific LAN and WAN infrastructure (and the state of IPv6 support for every router between the end user and the Perforce versioning service).

To illustrate just one possible scenario, a user working from home; even if they have an IPv6-based home network, their ISP or VPN provider may not fully support IPv6. We have consequently provided several variations on P4PORT to provide maximum flexibility and backwards compatibility for administrators and users during the transition from IPv4 to IPv6.

In mixed environments it is good practice to set the net.rfc3484 configurable to 1:

$ p4 configure set net.rfc3484=1

Doing so ensures RFC3484-compliant behavior for users who do not explicitly specify the protocol value; that is, if the client-side configurable net.rfc3484 is set to 1, and P4PORT is set to example.com:1666, or tcp:example.com:1666, or ssl:example.com:1666, the user’s operating system will automatically determine, for any given connection, whether to use IPv4 or IPv6 transport.

In multi-server environments, net.rfc3484, when set server-side, also controls the behavior of of host resolution when initiating server-to-server (or proxy, broker, etc.) communications.

Perforce does not require privileged access. For security reasons, do not run p4d as root or otherwise grant the owner of the p4d process root-level privileges.

Create an unprivileged UNIX user (for example, perforce) to manage p4d and (optionally) a UNIX group for it (for example, p4admin). Use the umask(1) command to ensure that the server root (P4ROOT) and all files and directories created beneath it are writable only by the UNIX user perforce, and (optionally) readable by members of the UNIX group p4admin.

Under this configuration, the Perforce service (p4d), running as UNIX user perforce, can write to files in the server root, but no users are able to read or overwrite its files. To grant access to the files created by p4d (that is, the depot files, checkpoints, journals, and so on) to trusted users, you can add the trusted users to the UNIX group p4admin.

Under a normal installation, the Perforce service runs on UNIX as a background process that waits for connections from users. To have p4d start up only when connections are made to it, using inetd and p4d -i, add the following line to /etc/inetd.conf:

p4dservice stream tcp nowait username /usr/local/bin/p4d p4d -i -r p4droot

and then add the following line to /etc/services:

p4dservice nnnn /tcp

where:

The "extra" p4d on the /etc/inetd.conf line must be present; inetd passes this to the OS as argv[0]. The first argument, then, is the -i flag, which causes p4d not to run as a background process, but rather to serve the single client connected to it on stdin/stdout. (This is the convention used for services started by inetd.)

This method is an alternative to running p4d from a startup script. It can also be useful for providing special services; for example, at Perforce, we have a number of test servers running on UNIX, each defined as an inetd service with its own port number.

There are caveats with this method:

After you set p4d's P4PORT and P4ROOT environment variables, start the service by running p4d in the background with the command:

$ p4d &

Although the example shown is sufficient to run p4d, you can specify other flags that control such things as error logging, checkpointing, and journaling.

$ p4d -r /usr/local/p4root -J /var/log/journal -L /var/log/p4err -p tcp64:[::]:1818 &

For information about the files that have been installed, see Installed files.

To shut down the Perforce service, use the command:

$ p4 admin stop

Only a Perforce superuser can use p4 admin stop.

To restart a running Perforce service (for example, to read a new license file), use the command:

$ p4 admin restart

Only a Perforce superuser can use p4 admin restart. On UNIX platforms, you can also use kill -HUP to restart the service.

In this manual, the terms Perforce Service and p4d are used interchangeably to refer to "the process which provides versioning services to Perforce applications" unless the distinction between a Windows server process or a service process is relevant.

The Perforce versioning service (p4d) can be configured to run as a Windows service (p4s.exe) process that starts at boot time, or as a server (p4d.exe) process that you invoke manually from a command prompt. To run a task as a Windows server, the user must be logged in because shortcuts in a user’s startup folder cannot be run until that user logs in.

The Perforce service (p4s.exe) and the Perforce server (p4d.exe) executables are copies of each other; they are identical apart from their filenames. When run, the executables use the first three characters of the name with which they were invoked (either p4s or p4d) to determine their behavior. (For example, invoking copies of p4d.exe named p4smyservice.exe or p4dmyserver.exe invoke a service and a server, respectively.)

By default, the Perforce installer configures Perforce as a Windows service..

By default, the Perforce service runs under the local System account. Because the System account has no network access, a real userid and password are required in order to make the Perforce service work if the metadata and depot files are stored on a network drive. The Perforce service is then configured with the supplied data and run as the specified user instead of System.

If you are installing your server root on a network drive, the Perforce installer (perforce.exe) requests a valid combination of userid and password at the time of installation. This user must have administrator privileges.

Although the Perforce service runs reliably using a network drive as the server root, there is still a marked performance penalty due to increased network traffic and slower file access. Consequently, Perforce recommends that the depot files and Perforce database reside on a drive local to the machine on which the Perforce service is running.

If you install Perforce as a service under Windows, the service starts whenever the machine boots. Use the Services applet in the Control Panel to control the Perforce service’s behavior.

To stop a Perforce service, use the command:

$ p4 admin stop

Only a Perforce superuser can use p4 admin stop.

For older revisions of Perforce, shut down services manually by using the Services applet in the Control Panel.

For information about the files that have been installed, see Installed files.

By default, the Perforce installer for Windows installs a single Perforce server as a single service. If you want to host more than one Perforce installation on the same machine (for instance, one for production and one for testing), you can either manually start Perforce servers from the command line, or use the Perforce-supplied utility svcinst.exe, to configure additional Perforce services.

Understanding the precedence of environment variables in determining Perforce configuration is useful when configuring multiple Perforce services on the same machine. Before you begin, read and understand Windows configuration parameter precedence.

To set up a second Perforce service:

We recommend that you install your first Perforce service using the Perforce installer. This first service is called Perforce and its server root directory contains files that are required by any other Perforce services you create on the machine.

C:\> p4d -V

C:\> mkdir c:\p4root2

C:\> copy c:\perforce\p4d.exe c:\p4root2
C:\> copy c:\perforce\p4d.exe c:\p4root2\p4s.exe
C:\> copy c:\perforce\license c:\p4root2\license

C:\> svcinst create -n Perforce2 -e c:\p4root2\p4s.exe -a

C:\> p4 set -S Perforce2 P4ROOT=c:\p4root2
C:\> p4 set -S Perforce2 P4PORT=1667
C:\> p4 set -S Perforce2 P4LOG=log2
C:\> p4 set -S Perforce2 P4JOURNAL=journal2

$ svcinst start -n Perforce2.

Under Windows, Perforce configuration parameters can be set in many different ways. When a Perforce application (such as p4 or P4V), or a Perforce server program (p4d) starts up, it reads its configuration parameters according to the following precedence:

When a Perforce service (p4s) starts up, it reads its configuration parameters from the environment according to the following precedence:

User environment variables can be set with any of the following:

System environment variables can be set with:

The server executable, p4d.exe, is normally found in your P4ROOT directory. To start the server, first make sure your current P4ROOT, P4PORT, P4LOG, and P4JOURNAL settings are correct; then run: %P4ROOT%\p4d

To start a server with settings different from those set by P4ROOT, P4PORT, P4LOG, or P4JOURNAL, use p4d command-line flags. For example:

C:\> C:\test\p4d -r c:\test -p 1999 -L c:\test\log -J c:\test\journal

starts a Perforce server process with a root directory of c:\test, listening to port 1999, logging errors to c:\test\log, and with a journal file of c:\test\journal. The p4d command-line flags are case-sensitive.

To stop the Perforce server, use the command:

C:\> p4 admin stop

For information about the files that have been installed, see Installed files.

Support for long file names is enabled by default in Perforce server versions 2015.2 or newer. For older versions of the Perforce server, you can enable long filename support on the server with the filesys.windows.lfn configurable.

Set filesys.windows.lfn to 1 to support filenames longer than 260 characters on Windows platforms. A file name length of up to 32,767 characters is allowed. Each component of the path is limited to 255 characters.

To set on the server, use a command like the following:

C:\> p4 configure set filesys.windows.lfn=1

Depending on the depth of your workspace path, you might also need to set this configurable on the client and/or proxy (which acts as a client). To set the configurable for a proxy, use a command like the following:

C:\> p4 set -S "Perforce Proxy" P4DEBUG=filesys.windows.lfn=1

Although older Perforce applications generally work with newer versions of Perforce, some features in new server releases require upgrades to Perforce applications. In general, users with older applications are able to use features available from the Perforce versioning service at the user application’s release level, but are not able to use the new features offered by subsequent upgrades to the service.

To upgrade Perforce to a newer version, your Perforce license file must be current. Expired licenses do not work with upgraded versions of Perforce.

Follow the instructions in this section if both your old and new versions are 2013.3 or later, or if both old and new versions are 2013.2 or earlier.

Read the Release Notes for complete information on upgrade procedures.

In general, Perforce upgrades require that you:

If you have any questions or difficulties during an upgrade, contact Perforce technical support.

Follow the instructions in this section if your old version is 2013.2 or earlier and your new version is 2013.3 or later.

Perforce 2013.3 contains major changes to the Perforce database implementation. These changes allow for increased concurrency and scalability, and increase the size limit for the db.* database files to 16TB.

Although the db.* database file format has changed, the checkpoint and journal file formats are identical. In order to upgrade from 2013.2 (or earlier) to 2013.3 (or later), you must restore the database from a checkpoint. To do this:

Perforce administrators can use the p4 verify filenames command to validate stored MD5 digests of each revision of the named files. The signatures created when users store files in the depot can later be used to confirm proper recovery in case of a crash: if the signatures of the recovered files match the previously saved signatures, the files were recovered accurately. If a new signature does not match the signature in the Perforce database for that file revision, Perforce displays the characters BAD! after the signature.

It is good practice to run p4 verify before performing your nightly system backups, and to proceed with the backup only if p4 verify reports no corruption.

For large installations, p4 verify can take some time to run. The server is also under heavy load while files are being verified, which can impact the performance of other Perforce commands. Administrators of large sites might want to perform p4 verify on a weekly basis, rather than a nightly basis.

If you ever see a BAD! signature during a p4 verify command, your database or versioned files might be corrupt, and you should contact Perforce Technical Support.