Helix Core Server Administrator Guide: Fundamentals (2019.1)

CPU

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.

Faster processors and memory in the machine where p4d executes might result in faster execution of p4d commands. Since 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. For example, most 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.

If you are using lockless reads, CPU speed is not as critical, but can still be helpful for good performance. Since some readers will no longer block a writer (and a writer will no longer block some readers), speeding commands through the server might not be as critical from a concurrency point of view. And since more commands might now run concurrently through the Helix Core server, 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 faster processors might need more processors and/or processors with more cores while maintaining the speed of the processors.

Note

If you are using SSL to secure client-server connections, choose a CPU that supports the AES instruction set. Helix server normally uses AES-256 to encrypt its SSL connections, so using a CPU that supports AES will minimize the encryption overhead: in most CPUs, it will eliminate the performance penalty.

Some processors and operating systems support dynamic frequency scaling, which allows the processor to vary power consumption by dynamically adjusting the processor voltage and core frequency. As more demand is placed on the processor, the voltage and core frequency increase. Until the processor is ramped up to full speed, p4d performance might be impacted. Although the power-saving capability of the dynamic frequency scaling feature is useful for mobile computers, it is not recommended for the machine where p4d executes.

Examples of dynamic frequency scaling include the following:

  • Intel SpeedStep - available on some Xeon processors and generally available on mobile computers
  • AMD PowerNow! - available on an array of AMD processors, including server-level processors

Both features are supported on Linux (and enabled by default in some SuSE distributions), Windows, and Mac OS X platforms. If this feature is enabled on the machine where p4d executes, we recommend disabling it. In some Linux distributions, such as SuSE, this feature can be disabled by setting the "powersaved" service to "off".

You might be able to determine the current speed of the processors on your computer. On Linux, the current speed of each core is reported on the "cpu MHz" line in the output from the cat /proc/cpuinfo OS command.