PHP Settings

PHP Settings: Performance Optimization and Configuration for rConfig V8

rConfig V8 ships and is supported on Apache with mod_php. This guide assumes that stack. If you have manually swapped your install to Nginx with PHP-FPM, the underlying principles still apply but the file paths and service names differ, contact rConfig support before making changes.

Proper PHP configuration directly impacts system performance, stability, and the ability to handle large-scale network management operations. PHP defaults are conservative and tuned for typical web workloads, not network configuration management systems that process large datasets and run long background operations. The settings in this guide eliminate the most common timeout errors, memory exhaustion failures, and performance bottlenecks.

The guide covers PHP 8.2, 8.3 and 8.4 across Ubuntu, Debian, RHEL, Rocky Linux and AlmaLinux. Wherever you see 8.x in a path or service name, substitute your installed PHP version.

Critical Concept: CLI vs Apache Configuration

Before you change anything, understand this. PHP runs in two distinct modes that read separate configuration files:

• CLI mode is used when you run php from the shell, when Horizon queue workers process jobs, and when scheduled artisan commands run via cron.
• Apache mode (mod_php) is used by Apache to serve the rConfig web interface to your browser.

Each mode has its own php.ini file, and changes to one do not affect the other.

The most common PHP configuration mistake

You edit php.ini, run php -i | grep memory_limit, see the new value, and assume the change worked. Then the rConfig web interface still shows the old value. This happens because php -i only reports the CLI value, but the web interface reads the Apache mod_php value. They are configured independently.

If you only update the CLI ini, the web interface, the System Optimization page, and any web-driven operation will continue to use the default (and lower) Apache values.

Always update both files, or update the Apache file specifically if your goal is to fix web-side limits.

Where each mode reads its config

OS Family	CLI ini	Apache (mod_php) ini
Ubuntu/Debian	/etc/php/8.x/cli/php.ini	/etc/php/8.x/apache2/php.ini
RHEL/Rocky/AlmaLinux (system PHP)	/etc/php.ini	/etc/php.ini
RHEL/Rocky/AlmaLinux (Remi PHP 8.x)	/etc/opt/remi/php8x/php.ini	/etc/opt/remi/php8x/php.ini

On Ubuntu and Debian the CLI and Apache split is physical, two separate files in two separate directories. On RHEL-family systems both modes share /etc/php.ini, so a single edit covers both, but you still need to restart the right services.

No FPM file? That is expected.

On Apache with mod_php there is no /etc/php/8.x/fpm/php.ini and no php8.x-fpm service. If you went looking for the FPM file and it didn’t exist, that’s not a problem with your install, it just means PHP is loaded directly into Apache as a module rather than via FPM. Edit the apache2/php.ini file instead.

Understanding Critical PHP Settings

Memory Limit

The memory_limit setting defines the maximum amount of memory a single PHP process can consume before being terminated. For rConfig operations, adequate memory allocation is essential when:

• Processing large configuration files from enterprise routers or switches
• Executing compliance checks across thousands of device configurations simultaneously
• Generating comprehensive reports with extensive historical data
• Performing bulk operations like policy assignments across device inventories
• Running backups that aggregate configuration data from entire repositories

Insufficient memory allocation manifests as “Allowed memory size exhausted” errors, typically during configuration downloads, report generation, or bulk operations.

Execution Time

The max_execution_time setting controls how long a PHP script can run before PHP automatically terminates it. This protects servers from runaway processes but can prematurely terminate legitimate long-running operations.

For rConfig, execution time becomes critical when:

• Downloading configurations from hundreds of devices in a single task
• Running comprehensive compliance evaluations across large device inventories
• Generating detailed audit reports spanning extended time periods
• Executing system backups that compress large configuration repositories
• Performing database maintenance operations on tables with millions of rows

The queue system mitigates much of this through background processing, but certain operations still require extended PHP execution windows.

Other Settings Worth Tuning

While memory_limit and max_execution_time are the most impactful, the following are commonly tuned at the same time:

• post_max_size, governs the maximum size of POST data, relevant for large config uploads or imports
• upload_max_filesize, governs the maximum size of an uploaded file
• max_input_vars, useful when bulk forms post very large payloads
• max_input_time, parsing time for incoming POST/GET data

Recommended Configuration Values

Memory Limit Guidelines

The right value depends on the size of your deployment, the size of the host, and what else runs on it. The two tables below give recommendations from two angles. Use whichever is more constraining for your environment.

By server RAM (dedicated rConfig host):

Server RAM	Recommended memory_limit	Suitable Deployment
4 GB	3072M (3 GB)	Small, under 500 devices
8 GB	6144M (6 GB)	Medium, 500 to 1,000 devices
16 GB	12288M (12 GB)	Large, 1,000 to 5,000 devices
32 GB+	28672M (28 GB)	Enterprise, 10,000+ devices

By device inventory (when RAM is not the limiting factor):

memory_limit	Suitable For
512M	Very small lab or pilot, under 50 devices
1024M (1 GB)	Small, 50 to 200 devices
2048M (2 GB)	Medium, 200 to 500 devices
4096M (4 GB)	Large, 500 to 1,500 devices
8192M (8 GB)	Very large, 1,500 to 5,000 devices
12288M+	Enterprise, 5,000+ devices

Note

The “by RAM” table assumes a dedicated rConfig server and allocates approximately 75 to 85 percent of available RAM to PHP, leaving headroom for the OS, MariaDB/MySQL, Apache, Redis, and Horizon workers. If you are running other memory-intensive applications on the same host, reduce the allocation accordingly.

Execution Time Guidelines

Environment Size	Recommended max_execution_time	Rationale
Small, under 100 devices	300 seconds (5 minutes)	Most operations complete within this window
Medium, 100 to 500 devices	600 seconds (10 minutes)	Bulk operations require extended processing
Large, 500 to 1,500 devices	900 seconds (15 minutes)	Comprehensive tasks span many devices
Enterprise, 1,500+ devices	1200 seconds (20 minutes)	Large-scale operations need maximum time

Note

While generous execution time limits accommodate large operations, the queue system provides a more robust solution for truly extensive tasks. Queue workers process jobs in the background with their own timeout management, separate from Apache execution limits. For deployments with thousands of devices, rely on the queue system for scalability rather than continually increasing max_execution_time on the web side.

Locating Your PHP Configuration Files

Before editing anything, confirm exactly which files are loaded by each mode on your server.

CLI

php -i | grep "Loaded Configuration File"
php -i | grep "Scan this dir for additional .ini files"

The first command shows the main CLI ini path. The second shows the directory scanned for drop-in conf.d files, which on Ubuntu and Debian is the typical place where extension settings (opcache, etc.) override the main file.

Apache (mod_php)

php -i only reports CLI values. To see what Apache is actually using, render phpinfo() from the web. This is the definitive way to confirm what your browser sees:

echo "<?php phpinfo(); ?>" | sudo tee /var/www/html/rconfig8/current/public/phpinfo.php

Browse to https://your-rconfig-server/phpinfo.php, search for Loaded Configuration File and the directives you care about. Then delete the file immediately:

sudo rm /var/www/html/rconfig8/current/public/phpinfo.php

Caution

phpinfo() exposes database credentials, environment variables, file paths, and extension details. Never leave it accessible on a production server. Delete it within minutes of creation.

Confirm Apache is using mod_php

If you are unsure whether your install is using mod_php or has been customised to use PHP-FPM, run:

# Ubuntu/Debian
sudo apache2ctl -M | grep -i php
dpkg -l | grep -E 'libapache2-mod-php|php.*-fpm'

# RHEL/Rocky/AlmaLinux
sudo httpd -M | grep -i php
rpm -qa | grep -E 'mod_php|php-fpm'

If you see php_module (or similar) loaded in Apache’s module list, you’re on mod_php. If you see proxy_fcgi_module and a running php-fpm service instead, your install has been customised, contact rConfig support before continuing.

Step-by-Step Configuration Procedure

Caution

Always create backups before modifying PHP configuration. Syntax errors in php.ini can prevent PHP from starting, taking rConfig offline until corrected. Where possible, validate changes in a non-production environment first.

Ubuntu/Debian

Step 1: Identify PHP version

php -v

Note the version, for example 8.3 or 8.4. All paths below assume that version, substitute as needed.

Step 2: Back up both configuration files

sudo cp /etc/php/8.x/apache2/php.ini /etc/php/8.x/apache2/php.ini.backup.$(date +%Y%m%d)
sudo cp /etc/php/8.x/cli/php.ini /etc/php/8.x/cli/php.ini.backup.$(date +%Y%m%d)

Step 3: Edit the Apache configuration file

sudo nano /etc/php/8.x/apache2/php.ini

Press Ctrl+W, type memory_limit, press Enter. Change:

memory_limit = 128M

to your target value, for example:

memory_limit = 6144M

Press Ctrl+W again, type max_execution_time, press Enter. Change:

max_execution_time = 30

to your target, for example:

max_execution_time = 600

Save with Ctrl+O, Enter, then Ctrl+X to exit.

Step 4: Edit the CLI configuration file

Apply the same values to the CLI ini so Horizon workers and scheduled artisan commands match:

sudo nano /etc/php/8.x/cli/php.ini

Update memory_limit and max_execution_time to the same values you used in Step 3.

Step 5: Restart Apache

A reload is not sufficient, php.ini changes only take effect on a full restart:

sudo systemctl restart apache2

Step 6: Restart Horizon so queue workers pick up the new CLI values

sudo systemctl restart rconfig-horizon

Step 7: Verify, see the Verification section below

RHEL/Rocky/AlmaLinux (System PHP)

This applies when you are using the PHP package shipped with the OS. For Remi-installed PHP, see the next tab.

Step 1: Identify PHP version and config

php -v
php -i | grep "Loaded Configuration File"

Step 2: Back up the configuration

sudo cp /etc/php.ini /etc/php.ini.backup.$(date +%Y%m%d)

On RHEL family the same /etc/php.ini is used for both CLI and Apache mod_php, so a single edit covers both modes.

Step 3: Edit /etc/php.ini

sudo vi /etc/php.ini

Press /, type memory_limit, press Enter. Press i to enter insert mode and update:

memory_limit = 6144M

Press Esc, then /, type max_execution_time, press Enter, i to insert, update:

max_execution_time = 600

Save with Esc, :wq, Enter.

Step 4: Restart Apache

sudo systemctl restart httpd

Step 5: Restart Horizon

sudo systemctl restart rconfig-horizon

RHEL/Rocky/AlmaLinux (Remi PHP 8.x)

If you installed PHP 8.3 or 8.4 from the Remi repository (common on rConfig V8 deployments because the OS-bundled PHP is often older than rConfig requires), the paths differ.

Step 1: Identify the Remi PHP version

php -v

Remi installs typically place the binary at /usr/bin/php via update-alternatives or a symlink. The actual config tree lives under /etc/opt/remi/php8x/.

Step 2: Back up the configuration

sudo cp /etc/opt/remi/php84/php.ini /etc/opt/remi/php84/php.ini.backup.$(date +%Y%m%d)

Replace php84 with php83, php82 etc. as appropriate.

Step 3: Edit the main ini

sudo vi /etc/opt/remi/php84/php.ini

Update memory_limit and max_execution_time as in the other tabs.

Step 4: Restart Apache

sudo systemctl restart httpd

Step 5: Restart Horizon

sudo systemctl restart rconfig-horizon

Verifying Configuration Changes

Verification is where most people get tripped up, because php -i only reports the CLI value. Verify CLI and Apache separately.

CLI verification

For CLI, queue workers, and scheduled jobs:

php -i | grep memory_limit
php -i | grep max_execution_time

Apache verification

phpinfo() rendered from the browser is the definitive check. There is no shell command that reports the Apache mod_php value reliably.

echo "<?php phpinfo(); ?>" | sudo tee /var/www/html/rconfig8/current/public/phpinfo.php

Browse to https://your-rconfig-server/phpinfo.php, search for memory_limit. Confirm the new value, then delete the file:

sudo rm /var/www/html/rconfig8/current/public/phpinfo.php

Verification Through rConfig

1. Navigate to System Settings >> System Optimization and review the displayed PHP values.
2. Attempt a resource-intensive operation, such as generating a large report.
3. Monitor System Settings >> Application Logs for memory or timeout errors.
4. If operations complete successfully without errors, configuration is adequate.

System Optimization page is cached

The values displayed on the System Optimization page are cached for 24 hours to avoid hammering the server with phpinfo() lookups. After updating PHP settings and restarting Apache, the page will continue to show the previous values until the cache expires.

To see the new values immediately, clear the cache:

cd /var/www/html/rconfig8/current
sudo php artisan rconfig:clear-all

Or, if you only want to clear the application cache:

sudo php artisan cache:clear

Refresh the page after running the clear command.

Troubleshooting Configuration Issues

Symptom: php -i shows the new value but the rConfig web interface and System Optimization page still show the old value

Diagnosis: This is the CLI vs Apache split in action. You updated the CLI ini, so php -i shows the new value, but the web interface reads from Apache mod_php, which still has the original value.

Resolution:

1. Edit the Apache ini at the path for your OS:

   • Ubuntu/Debian: /etc/php/8.x/apache2/php.ini
   • RHEL/Rocky/AlmaLinux (system PHP): /etc/php.ini
   • RHEL/Rocky/AlmaLinux (Remi): /etc/opt/remi/php8x/php.ini

2. Update memory_limit and any other directives to match what you set in the CLI ini.

3. Restart Apache (a reload is not enough):

   • Ubuntu/Debian: sudo systemctl restart apache2
   • RHEL family: sudo systemctl restart httpd

4. Verify via phpinfo() from the browser.

5. Clear the rConfig cache to refresh the System Optimization page:

   sudo php artisan rconfig:clear-all

Symptom: “I can’t find /etc/php/8.x/fpm/php.ini”

Diagnosis: rConfig V8 ships on Apache with mod_php, not Nginx with PHP-FPM. The FPM file does not exist on a default install, and that is expected.

Resolution: Edit the Apache ini instead, see the path table at the top of this page. If you genuinely need to confirm there is no FPM running:

# Ubuntu/Debian
systemctl list-units --all | grep -i php-fpm
dpkg -l | grep php-fpm

# RHEL family
systemctl list-units --all | grep -i php-fpm
rpm -qa | grep php-fpm

If those commands return nothing or no active service, you’re on mod_php as expected.

Symptom: System Optimization page still shows old values after Apache restart

Diagnosis: The page caches its readings for 24 hours.

Resolution:

cd /var/www/html/rconfig8/current
sudo php artisan rconfig:clear-all

Refresh the page. If it still shows old values, render phpinfo() from a browser to confirm what Apache is actually using. If phpinfo() shows the new value but the System Optimization page does not, raise a support ticket with the output of both.

Symptom: Changes Not Applied After Restart

Diagnosis: Verify the correct php.ini file was modified and Apache was fully restarted.

Possible causes:

• Modified the CLI ini instead of the Apache ini (or vice versa)
• Modified the wrong PHP version’s configuration (e.g., edited /etc/php/8.2/... when running PHP 8.4)
• Apache reloaded rather than fully restarted (mod_php picks up php.ini only on full restart)
• Syntax error in php.ini preventing PHP from loading

Resolution steps:

1. Confirm which php.ini is active for CLI:

   php -i | grep "Loaded Configuration File"

2. Confirm Apache is actually using mod_php and which version:

   # Ubuntu/Debian
   sudo apache2ctl -M | grep -i php
   
   # RHEL family
   sudo httpd -M | grep -i php

3. Confirm the version actually serving requests matches the version you edited. Render phpinfo() from the browser and read the version banner.

4. Check that Apache is running:

   sudo systemctl status apache2   # Ubuntu/Debian
   sudo systemctl status httpd     # RHEL family

5. Review Apache error logs for PHP startup errors:

   • Ubuntu/Debian: /var/log/apache2/error.log
   • RHEL family: /var/log/httpd/error_log

6. If syntax errors exist, restore from the backup created in Step 2 and retry.

Symptom: Operations Still Failing with Memory Errors

Diagnosis: Memory allocation insufficient for operation scale, or a memory leak is present.

Possible causes:

• Configuration processing requires more memory than allocated
• Memory leak in PHP extensions or rConfig code
• Multiple concurrent operations exhausting available memory
• Database queries returning extremely large result sets

Resolution steps:

1. Review System Logs for the specific memory exhaustion message and the operation that triggered it.
2. Identify whether the failing operation is web-driven (Apache memory limit applies) or queue-driven (CLI memory limit applies).
3. Increase the relevant memory_limit incrementally, typically by 2 to 4 GB.
4. If failures persist despite a generous allocation, contact rConfig support for memory profiling.
5. For very large operations, break them into smaller batches via tasks or schedules.

Symptom: Queue Workers Ignore PHP Configuration Changes

Diagnosis: Queue workers run under CLI PHP, not Apache. If you only updated the Apache ini, Horizon still uses the old CLI values.

Possible causes:

• CLI php.ini not updated
• Horizon not restarted after the change
• Supervisor configuration enforces its own limits
• Environment variables in the Horizon service unit override ini values

Resolution steps:

1. Verify CLI configuration:

   php -i | grep memory_limit
   php -i | grep max_execution_time

2. If CLI values are wrong, update the CLI ini for your OS and restart Horizon.

3. Restart Horizon so workers reload:

   cd /var/www/html/rconfig8/current
   sudo php artisan horizon:terminate
   sudo systemctl restart rconfig-horizon

4. Inspect the Horizon service unit and supervisor config for explicit overrides:

   sudo systemctl cat rconfig-horizon
   sudo cat /etc/supervisor/conf.d/rconfig-horizon.conf 2>/dev/null

Best Practices

Security

Delete phpinfo.php immediately after verification. It exposes database credentials, API keys, and security-sensitive settings. Never leave it on a production server.

Balance resource allocation with system stability. Excessively high memory limits allow runaway processes to consume all RAM and crash the host. Stay within 75 to 85 percent of available RAM on dedicated servers, and lower if other workloads share the host.

Monitor for resource exhaustion. Track unusual patterns of CPU or memory consumption. Implement rate limiting on exposed API endpoints.

Performance

Align PHP settings with deployment scale. As device inventories grow, revisit PHP configuration quarterly. A memory_limit appropriate for 100 devices will prove insufficient at 1,000.

Prefer the queue system over ever-larger execution times. Truly large operations belong in Horizon jobs with their own timeout management, not in synchronous web requests.

Measure actual usage. Use top, htop, or your monitoring stack to observe real PHP memory consumption during peak operations. Empirical data beats estimates.

Restart Apache regularly on high-volume systems. mod_php worker processes accumulate memory over time. Schedule weekly or monthly restarts during maintenance windows.

Organization

Document configuration changes. Note current values, when they were changed, and why. This prevents confusion during troubleshooting and helps with capacity planning.

Version-control configuration files. Store copies of php.ini in your config management or version control system. This enables rapid restoration after rebuilds and provides an audit trail.

Test in non-production first. Validate changes in staging before applying to production wherever possible.

Maintenance

Review PHP configuration during major version upgrades. A jump from 8.2 to 8.4 may introduce different defaults or require migration of deprecated directives. After any PHP upgrade, re-verify all customizations.

Coordinate with OS updates. Distribution upgrades sometimes replace customized configuration files with package defaults. After OS updates, verify and reapply settings.

Watch for deprecation warnings in logs. Newer PHP releases deprecate functions and directives that were valid in older versions. Address them before they become hard errors in the next major version.

Quick Reference

Memory Limit (consolidated)

memory_limit	Suitable Deployment	Suggested host RAM
512M	Lab / pilot, under 50 devices	2 GB+
1024M (1 GB)	Small, 50 to 200 devices	4 GB+
2048M (2 GB)	Medium, 200 to 500 devices	4 to 8 GB
4096M (4 GB)	Large, 500 to 1,500 devices	8 GB+
6144M (6 GB)	Medium-large dedicated host	8 GB
8192M (8 GB)	Very large, 1,500 to 5,000 devices	16 GB+
12288M (12 GB)	Large dedicated host	16 GB
28672M (28 GB)	Enterprise, 10,000+ devices	32 GB+

Execution Time

max_execution_time	Suitable For
300 (5 minutes)	Small, under 100 devices
600 (10 minutes)	Medium, 100 to 500 devices
900 (15 minutes)	Large, 500 to 1,500 devices
1200 (20 minutes)	Enterprise, 1,500+ devices

Configuration File Locations

OS	CLI	Apache (mod_php)
Ubuntu/Debian	/etc/php/8.x/cli/php.ini	/etc/php/8.x/apache2/php.ini
RHEL/Rocky/AlmaLinux (system PHP)	/etc/php.ini	/etc/php.ini
RHEL/Rocky/AlmaLinux (Remi)	/etc/opt/remi/php8x/php.ini	/etc/opt/remi/php8x/php.ini

Service Restart Commands

# Ubuntu/Debian
sudo systemctl restart apache2

# RHEL/Rocky/AlmaLinux
sudo systemctl restart httpd

# Horizon (all OS)
sudo systemctl restart rconfig-horizon

# rConfig caches (run from /var/www/html/rconfig8/current)
sudo php artisan rconfig:clear-all

Related Documentation

• System Requirements, hardware and software prerequisites including PHP version requirements
• Installation Guide, initial rConfig setup including PHP configuration
• Horizon Queue Manager, background job processing that relies on CLI PHP configuration
• System Logs, viewing PHP errors and exceptions
• Performance Tuning, comprehensive performance optimization strategies

Summary

Proper PHP configuration is fundamental to rConfig V8 performance and stability. The single most important concept to internalize is the CLI vs Apache split, the web interface and the command-line read separate configuration files on Ubuntu and Debian, and changes to one do not propagate to the other. On RHEL family the file is shared but the principle still holds, both modes need the right values and both services need to be restarted. Verifying with php -i alone is not sufficient.

Key takeaways:

• rConfig V8 ships on Apache with mod_php. There is no FPM service or FPM ini file on a default install.
• Update both CLI and Apache ini files (Ubuntu/Debian) or the shared /etc/php.ini (RHEL family), then restart Apache and Horizon.
• Allocate 75 to 85 percent of host RAM to PHP memory_limit on dedicated rConfig servers.
• Scale execution time with device count, but lean on the queue system for very large operations rather than ever-higher Apache timeouts.
• Verify each mode separately, php -i for CLI, phpinfo() from a browser for Apache.
• Clear the rConfig cache (php artisan rconfig:clear-all) after changes so the System Optimization page reflects the new values, the page is otherwise cached for 24 hours.
• Always back up before editing so you can recover quickly from a syntax error.
• Always fully restart Apache after editing php.ini, a reload will not pick up the changes.

Regular review and adjustment of PHP settings as deployments grow ensures rConfig maintains reliable, performant operations at scale. When configuration adjustments prove insufficient, contact rConfig support for assistance with performance profiling and advanced optimization strategies.