4.2.5 Features Part 2: Use Spare RAM for Opcode Caching withPHP suEXEC ProcessGroup!

The new PHP suEXEC ProcessGroup mode allows shared hosting providers with extra memory to get better PHP performance through per-user opcode caching, plus allow custom php.ini’s and CloudLinux’s PHP Selector, too.

Background

Last year, we introduced PHP suEXEC daemon mode. It’s been popular for a number of reasons, most notably because forking child processes from a parent process is faster and less resource-intensive than spawning brand new processes and because it allows for efficient opcode caching in shared hosting, something that was unheard of before. Daemon mode increased speed and saved resources. Its biggest downside is its incompatibility with custom php.ini’s.

What ProcessGroup does

The new PHP suEXEC ProcessGroup allows hosts to leverage extra RAM into get even greater performance gains through per-user opcode caching. It is set up similarly to PHP-FPM pools. ProcessGroup provisions a parent process for each ProcessGroup user. This parent process runs as the owner of the virtual host’s document root and acts as a personal daemon mode for that user. When that user needs a PHP process, the parent process spawns a child process. Because all processes in each process group are spawned by the same parent, they have less overhead than creating brand new processes and can share opcode cache. Unlike daemon mode, they don’t have to share that cache with everyone else.

More powerful opcode caching

Just like in daemon mode, the opcode cache is not flushed needlessly because the parent process stays running. In daemon mode, however, all users share one large opcode cache. If there are many users, the opcode cache can fill up and each user’s scripts may get bumped off the cache before they’re accessed very much. With a personal opcode, your scripts stay in your cache where they can be used many times (unless you fill up the cache yourself). The idea is to allow each user a bigger opcode cache that they can make more use of.

Still suEXEC secure

Because each parent process and all child processes run as the owner of the vhost’s document root, you get the same security you’ve always gotten from suEXEC — a necessity for shared hosting.

Fast process forking

As in daemon mode, new processes are forked not created brand new. This is faster and less resource-intensive than suPHP or PHP-FPM.

Allows custom php.ini

Because each process group has its own parent process, this means PHP suEXEC ProcessGroup is compatible with custom php.ini’s and CloudLinux’s PHP Selector.

Greater memory requirements

ProcessGroup keeps one parent process running in addition to all their child processes. This creates a lot of extra processes that you wouldn’t have in LiteSpeed’s normal suEXEC or daemon mode. It should be noted, though, that ProcessGroup is still more efficient than something like PHP-FPM pools, which keeps one process in each pool running at all times. LSWS will kill process group parent processes when they’ve been idle for a certain amount of time.

ProcessGroup’s personal opcode caches also mean that each user needs to have a certain amount of memory set aside for opcode caching. Unless you have a lot of RAM for this, these personal opcode caches can end up being rather small. ProcessGroup is really meant for hosts that are willing to use extra memory (on extra parent processes and opcode cache partitions) to see performance enhancements.

Can be set at the server or vhost level

ProcessGroup is set through a directive in your httpd.conf files at either the server or virtual host level (more on this later). Putting this directive at the vhost level allows you to decide which users get a personal opcode cache.

Be careful

There are some configuration risks with ProcessGroup:

1. If you portion out too much memory for per-user opcode caches, you could run out of memory. (When you put it like that, it seems obvious, doesn’t it?)
2. The directive that signals LSWS to use ProcessGroup is a special LiteSpeed-only directive. Apache will not understand this directive and may crash if you switch back to Apache without taking proper precautions! You need to separate the ProcessGroup directives with <IfModule LiteSpeed> .

And, with that, we’re at the configuration section:

Configuration

Enabling ProcessGroup

ProcessGroup is enabled by placing the directive LSPHP_ProcessGroup in an httpd.conf file. This can be done at the server or virtual host level. If done at the server level, all virtual hosts will use ProcessGroup. If done at the vhost level, only that vhost will use ProcessGroup. An example configuration would look like this:

<IfModule LiteSpeed>
LSPHP_ProcessGroup on
LSPHP_Workers 15
</IfModule>

Note the <IfModule LiteSpeed> . As explained above, LSPHP_ProcessGroup and LSPHP_Workers are LiteSpeed-specific directives. Apache will not understand them and may crash if they are not protected.

Additional configurations

• LSPHP_Workers sets the maximum number of child processes that the parent process can spawn. It is optional. If set, it will override PHP suEXEC Max Conn setting (WebAdmin console > Configuration > Server > General > Using Apache Configuration File).
• Per-user opcode cache size is set in your php.ini file. How to set this depends on what opcode cache you’re using.
• The Max Idle Time setting (WebAdmin console > Configuration > External App > your external application) will control how long before idle parent processes are killed.

That should be enough to get you started. We’ll be making additions to our documentation, website, and wiki to explain anything further. Happy LiteSpeed-ing!