CPU

CPU resource consumption can increase due to factors such as:

• complexity in the protections table
• compression and decompression
• lockless reads in some situations, although lockless reads are generally better for performance than file locking (see db.peeking)

When considering a CPU choice, we recommend the maximum clock rate that is available on the number of cores required for your typical workload. For detailed guidance for your typical workload, contact Helix Core Consulting.

Faster processors and memory in the machine where p4d executes might result in faster execution of p4d commands. Because portions of some commands acquire and hold resources that might block other commands, it is important that these portions of the commands execute as fast as possible. Some p4d commands have a compute phase during which shared locks are acquired and held on some of the db.* files. A shared lock on a db.* file blocks an operation that writes to the same db.* file. If the data needed for a command’s compute phase is cached within the operating system’s filesystem cache, only the processor and memory speed constrains the compute phase. Given the list of Commands implementing lockless reads, speeding commands through the server with a fast CPU might not be as critical from a concurrency point of view. Many commands can run concurrently through the Helix Core Server, so more CPU cores might be better utilized.

The complexity of the site’s protections table and of client views can affect CPU requirements. You can monitor CPU utilization using OS utilities such as top (on Linux and Unix) and perfmon (on Windows). Installations with high CPU utilization on the machine where p4d executes that are already using fast processors might need more processors or processors with more cores.