Skip to main content

PHP Optimization Foundation

PHP is the runtime that executes WordPress core, themes, and plugins for any request that is not served from page cache (admin, logged-in, checkout, AJAX, and cache misses). Optimizing PHP is mostly about reducing repeated work (OPcache) and sizing concurrency (workers) so dynamic requests stay fast and stable under load.

Quick Summary
  • Enable OPcache and size it so it does not churn.
  • Size PHP workers based on available RAM (too many workers causes swapping/OOM).
  • On OpenLiteSpeed, validate using the lsphp binary (LSAPI). php -i shows CLI config and may not match what WordPress uses.

How a WordPress Request Uses PHP​

wordpress-request-path.txt
Browser
  -> OpenLiteSpeed (web server)
  -> PHP via LSAPI (lsphp)
  -> WordPress bootstrap + plugins + theme
  -> Database / Redis / external APIs
  -> Response (HTML/JSON)

On OpenLiteSpeed, most PHP runtime tuning advice maps to the same two concepts:

  • OPcache: reduce repeated PHP compilation work.
  • LSAPI children (workers): size the lsphp process pool so dynamic requests don't queue and the server stays within RAM.

Two things determine how this feels for real users:

  • How much work each request does (OPcache helps reduce repeated compilation).
  • How many requests you can process at once without running out of RAM (worker sizing).

Workers: Concurrency and Memory​

Each dynamic request needs an available PHP worker. If all workers are busy, requests queue and you see slow admin pages, stalled AJAX, and timeouts during checkout.

On OpenLiteSpeed, these workers are lsphp (LSAPI) processes. The main concurrency knob is the LSAPI children/process count (commonly configured via PHP_LSAPI_CHILDREN in the lsphp External App).

OpenLiteSpeed WebAdmin path: Server Configuration -> External App -> lsphp -> Environment.

At the same time, each worker consumes RAM. If you size too many workers for the machine, the OS will swap or the OOM killer will terminate services.

Rule of thumb:

  • Measure an average worker memory footprint (RSS).
  • Keep lsapi_children * worker_rss within your RAM budget, leaving headroom for the OS, DB, Redis, and buffers.

If you need help with the full memory stack, see Memory Limits.

OPcache: The Highest-Leverage PHP Setting​

OPcache stores compiled PHP bytecode in shared memory so PHP does not have to recompile WordPress files on every request.

OPcache does not replace page cache, object cache, or database tuning. It mainly reduces CPU overhead and improves tail latency on dynamic requests.

Key directives you'll tune later:

  • opcache.memory_consumption
  • opcache.max_accelerated_files
  • opcache.interned_strings_buffer
  • opcache.validate_timestamps and opcache.revalidate_freq
  • opcache.save_comments (important for many WordPress plugins)

Baseline Checks​

Confirm the PHP Version OpenLiteSpeed Uses (LSAPI)​

check-openlitespeed-lsphp-version.sh
# List installed LSAPI PHP binaries (paths may vary by distro/panel)
ls -1 /usr/local/lsws/lsphp*/bin/lsphp 2>/dev/null

# Example: check PHP 8.2 LSAPI binary
/usr/local/lsws/lsphp82/bin/lsphp -v

Confirm OPcache Is Installed and Enabled (LSAPI)​

check-opcache-module-lsphp.sh
# Replace lsphp82 with your configured OpenLiteSpeed PHP version
/usr/local/lsws/lsphp82/bin/lsphp -m | grep -i opcache
check-opcache-settings-lsphp.sh
# Replace lsphp82 with your configured OpenLiteSpeed PHP version
/usr/local/lsws/lsphp82/bin/lsphp -i | grep -E 'opcache\.enable|opcache\.memory_consumption|opcache\.max_accelerated_files'
CLI vs OpenLiteSpeed (LSAPI) Settings

php -i and php -m show the system CLI configuration, which is often not the same PHP binary/config that OpenLiteSpeed uses for WordPress.

For OpenLiteSpeed, use the matching lsphp binary (example path: /usr/local/lsws/lsphp82/bin/lsphp) or confirm via a protected phpinfo() page.

To confirm the settings your site actually uses, check via a protected phpinfo() page (or your hosting panel) and then remove/lock it down.

Common Mistakes & Mitigation Strategy​

Configuration FailureOperational SymptomRemediation Protocol
OPcache disabledHigh CPU on dynamic pages; inconsistent response time on cache misses.Enable OPcache and tune memory_consumption + max_accelerated_files.
Too many workersRAM hits 100%, swapping begins, services restart or crash.Reduce worker counts and keep headroom. Size workers based on measured RSS.
Memory exhausted errorsImports/backups fail; random 500 errors in wp-admin.Increase memory_limit only if the server has RAM headroom, and fix the underlying cause (plugin behavior, worker sizing).

What's Next​