Quantum Ink

Writing about the future as it unfolds.

PHP 8.3 setup for enhanced WordPress speed on DirectAdmin

How to Configure PHP 8.3 for Maximum WordPress Performance on DirectAdmin

, , ,

Series: WordPress Performance on DirectAdmin (Rocky Linux 9)

Phase 2: PHP & Runtime — Part 5 of 30

How to Configure PHP 8.3 for Maximum WordPress Performance on DirectAdmin (Rocky Linux 9)

This article is part 5 of the “WordPress Performance on DirectAdmin (Rocky Linux 9)” series (slug: wp-perf-da), in Phase 2: PHP & Runtime. Here we focus on practical PHP 8.3 tuning for WordPress on DirectAdmin-managed servers.

1. Prerequisites and context

Assumptions:

  • Rocky Linux 9 with DirectAdmin installed.
  • CustomBuild 2.x managing PHP versions.
  • PHP-FPM enabled (per-user or per-domain pools).
  • Web stack: Apache + PHP-FPM and/or NGINX reverse proxy (DirectAdmin defaults).

Key DirectAdmin specifics to keep in mind:

  • PHP-FPM pool configs are generated from DirectAdmin templates; manual edits may be overwritten.
  • Per-domain settings are usually controlled via Custom HTTPD/NGINX Config and PHP Settings in the panel.
  • Global PHP-FPM and php.ini defaults come from CustomBuild and templates under /usr/local/directadmin/data/templates/.

2. Installing and selecting PHP 8.3 in DirectAdmin

2.1 Enable PHP 8.3 via CustomBuild

Risk: low (service restarts; brief PHP downtime during version switch).

Check current PHP configuration:

sudo /usr/local/directadmin/custombuild/build options | egrep 'php[0-9]_release|php[0-9]_mode'

Set PHP 8.3 as one of the versions (adjust if you already have multiple PHP versions):

cd /usr/local/directadmin/custombuild

# Set PHP 8.3 as php1 (primary PHP)
sudo ./build set php1_release 8.3
sudo ./build set php1_mode php-fpm

# Optional: keep PHP 8.1 as secondary
sudo ./build set php2_release 8.1
sudo ./build set php2_mode php-fpm

# Rebuild PHP and PHP-FPM
sudo ./build php n
sudo ./build php_fpm n

# Restart web stack
sudo systemctl restart php-fpm81 php-fpm83 httpd nginx 2>/dev/null || true

Confirm PHP 8.3 is available:

php83 -v
php -v   # depending on CLI default

2.2 Set domain to use PHP 8.3

In DirectAdmin (per domain):

  • User Level > Domain Setup > Select Domain > PHP Version Selector
  • Choose PHP 8.3 (php-fpm) for the domain.

Verify from the document root with WP-CLI:

cd /home/USERNAME/domains/example.com/public_html
wp core version --allow-root
wp --info --allow-root

Ensure WP-CLI sees PHP 8.3 in wp --info output (or call php83 explicitly if needed).

3. Baseline PHP 8.3 configuration for WordPress

On DirectAdmin with CustomBuild, global php.ini for PHP 8.3 is typically:

  • /usr/local/php83/lib/php.ini (custombuild-managed)

Risk: moderate (misconfiguration can break all PHP 8.3 sites). Always back up:

sudo cp /usr/local/php83/lib/php.ini /usr/local/php83/lib/php.ini.bak.$(date +%F)

3.1 Core performance-related php.ini settings

Good starting values for typical WordPress sites (single site or small multisite, 2–8 GB RAM):

sudo sed -i 's/^memory_limit.*/memory_limit = 256M/' /usr/local/php83/lib/php.ini
sudo sed -i 's/^max_execution_time.*/max_execution_time = 60/' /usr/local/php83/lib/php.ini
sudo sed -i 's/^max_input_time.*/max_input_time = 60/' /usr/local/php83/lib/php.ini
sudo sed -i 's/^post_max_size.*/post_max_size = 64M/' /usr/local/php83/lib/php.ini
sudo sed -i 's/^upload_max_filesize.*/upload_max_filesize = 64M/' /usr/local/php83/lib/php.ini

# Ensure OPcache and realpath_cache are tuned
sudo grep -q '^opcache.enable=' /usr/local/php83/lib/php.ini || \
  echo 'opcache.enable=1' | sudo tee -a /usr/local/php83/lib/php.ini

sudo grep -q '^opcache.enable_cli=' /usr/local/php83/lib/php.ini || \
  echo 'opcache.enable_cli=1' | sudo tee -a /usr/local/php83/lib/php.ini

sudo grep -q '^opcache.memory_consumption=' /usr/local/php83/lib/php.ini || \
  echo 'opcache.memory_consumption=256' | sudo tee -a /usr/local/php83/lib/php.ini

sudo grep -q '^opcache.interned_strings_buffer=' /usr/local/php83/lib/php.ini || \
  echo 'opcache.interned_strings_buffer=16' | sudo tee -a /usr/local/php83/lib/php.ini

sudo grep -q '^opcache.max_accelerated_files=' /usr/local/php83/lib/php.ini || \
  echo 'opcache.max_accelerated_files=20000' | sudo tee -a /usr/local/php83/lib/php.ini

sudo grep -q '^opcache.validate_timestamps=' /usr/local/php83/lib/php.ini || \
  echo 'opcache.validate_timestamps=1' | sudo tee -a /usr/local/php83/lib/php.ini

sudo grep -q '^opcache.revalidate_freq=' /usr/local/php83/lib/php.ini || \
  echo 'opcache.revalidate_freq=2' | sudo tee -a /usr/local/php83/lib/php.ini

sudo grep -q '^realpath_cache_size=' /usr/local/php83/lib/php.ini || \
  echo 'realpath_cache_size=256k' | sudo tee -a /usr/local/php83/lib/php.ini

sudo grep -q '^realpath_cache_ttl=' /usr/local/php83/lib/php.ini || \
  echo 'realpath_cache_ttl=300' | sudo tee -a /usr/local/php83/lib/php.ini

Then reload PHP-FPM 8.3:

sudo systemctl reload php-fpm83

3.2 Per-domain overrides (user-level php.ini)

DirectAdmin supports per-user/per-domain overrides via php.ini or .user.ini in the document root, depending on the PHP-FPM template.

Check the FPM pool config for the domain to see if php_admin_value or php_value are used:

grep -R "example.com" /usr/local/php83/etc/php-fpm.d 2>/dev/null

If the template allows php_admin_value, use DirectAdmin’s PHP Settings per-domain to override memory_limit, etc., instead of editing pool files directly (which will be overwritten by CustomBuild).

4. Tuning PHP-FPM pools for WordPress

4.1 Locate and understand pool configs

DirectAdmin with PHP 8.3 FPM typically stores pools under:

  • /usr/local/php83/etc/php-fpm.d/USERNAME.conf (per-user pool)

List pools:

ls -1 /usr/local/php83/etc/php-fpm.d/

Warning (overwrites): Manual edits to these files may be lost when DirectAdmin/CustomBuild rewrites configs. For persistent changes, adjust:

  • DirectAdmin > PHP-FPM Configuration (if available in your version)
  • or templates in /usr/local/directadmin/data/templates/php-fpm* and then run ./build rewrite_confs.

4.2 Recommended FPM process manager settings

For most WordPress sites, use dynamic with conservative limits.

Example pool section (conceptual; apply via template or DA interface):

[USERNAME]
user = USERNAME
group = USERNAME
listen = /usr/local/php83/sockets/USERNAME.sock
pm = dynamic
pm.max_children = 10
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 5
pm.max_requests = 500
request_terminate_timeout = 120
php_admin_value[memory_limit] = 256M

Good starting points based on server RAM (per user pool):

  • 2 GB RAM: pm.max_children = 5, pm.start_servers = 2, pm.max_spare_servers = 3
  • 4 GB RAM: pm.max_children = 10, pm.start_servers = 3, pm.max_spare_servers = 5
  • 8+ GB RAM: pm.max_children = 20 (or more, based on profiling)

Estimate pm.max_children from memory usage:

  1. Find average PHP-FPM 8.3 process RSS under load: 
    ps -o pid,rss,command -C php-fpm83 | head
  2. Convert RSS to MB (rss_kb / 1024) and allocate no more than ~40–50% of system RAM to PHP-FPM.

Apply template changes (if you edited templates):

cd /usr/local/directadmin/custombuild
sudo ./build update
sudo ./build rewrite_confs
sudo systemctl reload php-fpm83

4.3 FastCGI timeouts (Apache/NGINX)

For heavy admin operations or slow plugins, align timeouts with max_execution_time.

In DirectAdmin templates (conceptual locations):

  • Apache templates: /usr/local/directadmin/data/templates/custom/httpd-php-fpm.conf
  • NGINX templates: /usr/local/directadmin/data/templates/custom/nginx_php.conf

Look for directives such as:

ProxyTimeout 120
ProxySet timeout=120

fastcgi_read_timeout 120s;

Set them to 120s max for WordPress admin, then rebuild configs:

cd /usr/local/directadmin/custombuild
sudo ./build rewrite_confs
sudo systemctl reload httpd nginx

5. OPcache tuning for WordPress

5.1 Core OPcache directives

In /usr/local/php83/lib/php.ini (already partially set above), verify or adjust:

opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=2
opcache.fast_shutdown=1
opcache.save_comments=1

For very plugin-heavy sites (WooCommerce, builders, many plugins), you may increase:

  • opcache.memory_consumption=256–512
  • opcache.max_accelerated_files=40000

Reload PHP-FPM 8.3:

sudo systemctl reload php-fpm83

5.2 Verifying OPcache usage

Install a simple OPcache status script in a protected location, or use CLI:

php83 -r 'print_r(opcache_get_status());' | head -n 40

Check memory_usage and opcache_statistics to ensure you aren’t hitting opcache_full frequently.

6. Testing and benchmarking PHP 8.3 changes

6.1 Quick functional checks

After any PHP or FPM change:

  • Check FPM status: 
    sudo systemctl status php-fpm83 --no-pager
  • Check logs: 
    sudo tail -n 50 /var/log/php-fpm83/error.log 2>/dev/null || \
  sudo journalctl -u php-fpm83 -n 50 --no-pager
  • Check Apache/NGINX: 
    sudo tail -n 50 /var/log/httpd/error_log
sudo tail -n 50 /var/log/nginx/error.log 2>/dev/null || true

6.2 WP-CLI performance sanity checks

From the site root:

cd /home/USERNAME/domains/example.com/public_html

# Measure basic load time via CLI
time php83 -d display_errors=0 wp --allow-root eval 'echo "OK
";'

# Run a simple page generation
time php83 -d display_errors=0 wp --allow-root eval 'require "wp-load.php"; $p = get_post(1); echo $p->post_title . "
";'

Compare timings before and after tuning; large regressions indicate misconfiguration.

6.3 HTTP-level benchmarking (curl / wrk / k6)

Warning: Load tests can impact production performance. Run off-peak or against staging.

Basic latency check:

curl -w "@-" -o /dev/null -s https://example.com <<'EOF'
    time_namelookup:  %{time_namelookup}

       time_connect:  %{time_connect}

    time_appconnect:  %{time_appconnect}

   time_pretransfer:  %{time_pretransfer}

      time_redirect:  %{time_redirect}

 time_starttransfer:  %{time_starttransfer}

                    ----------

         time_total:  %{time_total}

EOF

Install wrk on Rocky 9 if needed (via EPEL or build from source). Example:

# Example: 50 connections, 200 threads, 30s
wrk -t200 -c50 -d30s https://example.com/

Monitor PHP-FPM during load:

watch -n 2 "ps -o pid,rss,cmd -C php-fpm83 | head; echo '---'; sudo tail -n 5 /var/log/php-fpm83/error.log"

7. Error visibility and production safety

For production, keep error display off and log to files:

sudo sed -i 's/^display_errors.*/display_errors = Off/' /usr/local/php83/lib/php.ini
sudo sed -i 's/^log_errors.*/log_errors = On/' /usr/local/php83/lib/php.ini
sudo sed -i 's|^error_log.*|error_log = /var/log/php-fpm83/php_errors.log|' /usr/local/php83/lib/php.ini

sudo mkdir -p /var/log/php-fpm83
sudo chown root:apache /var/log/php-fpm83
sudo chmod 750 /var/log/php-fpm83

sudo systemctl reload php-fpm83

Tail logs when testing new changes:

sudo tail -f /var/log/php-fpm83/php_errors.log /var/log/httpd/error_log

8. DirectAdmin template considerations

To keep tuning persistent across rebuilds:

  • Copy default templates to custom before editing: 
    cd /usr/local/directadmin/data/templates

# Example for php-fpm 8.3 templates (names may vary)
sudo cp php-fpm.conf php-fpm.conf.custom
sudo cp php-fpm_pool.conf php-fpm_pool.conf.custom
  • Edit *.custom files to adjust pm.* settings or socket paths.
  • Apply: 
    cd /usr/local/directadmin/custombuild
sudo ./build rewrite_confs
sudo systemctl reload php-fpm83 httpd nginx

Always document template changes; they affect all users/pools generated from those templates.

9. Quick checklist: PHP 8.3 performance baseline

  • PHP 8.3 installed via CustomBuild and selected for the domain.
  • Global php.ini tuned:
    • memory_limit=256M (or higher if justified).
    • Reasonable max_execution_time, post_max_size, upload_max_filesize.
    • OPcache enabled with 256 MB and 20k+ files.
  • PHP-FPM pool:
    • pm=dynamic with pm.max_children sized to RAM.
    • pm.max_requests=500 to mitigate leaks.
    • Timeouts aligned with WordPress needs (up to 120s for admin).
  • Apache/NGINX fastcgi/proxy timeouts in sync with PHP timeouts.
  • Error display off, logging enabled to dedicated PHP log.
  • Changes persisted via DirectAdmin templates where appropriate.
  • Performance verified via WP-CLI and HTTP benchmarking.

This article offers general technical guidance. Validate all configurations in a safe environment before applying them to production.

Previous: DirectAdmin vs cPanel for WordPress Performance

Next: PHP-FPM vs mod_php: Which Is Faster for WordPress?

Smart reads for curious minds

We don’t spam! Read more in our privacy policy

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *