PHP Auto-Configuration
Auto-Configurations for PHP Application Servers
Automatic optimisation can be disabled when custom values are required. Manual settings should be applied carefully because unsuitable values can reduce performance or make the server unstable.
Auto-Configuration Example
For example, consider an Apache PHP application server with a limit of 16 Cloudlets. Its prefork-module settings are calculated according to the resources available to the container.
After increasing the server limit to 32 Cloudlets and refreshing /etc/httpd/conf/httpd.conf, the related directives are recalculated automatically.
Disable Automatic Optimisation
Automatic optimisation must be disabled before manually changing auto-managed directives. Otherwise, custom values can be replaced during a container restart or update.
PHP_MEMORY_LIMIT and PHP_MAX_EXECUTION_TIME can adjust the PHP memory limit and maximum execution time without disabling automatic optimisation.
Smart Auto-Configuration
For LiteSpeed-based stacks, including LiteSpeed Web Server and LLSMP, set the JELASTIC_AUTOCONFIG environment variable to false or a disabled value.
Legacy Implementation
Apache PHP and NGINX PHP use an older optimisation mechanism. Remove the appropriate marker from the relevant configuration file before applying custom values:
- Apache PHP: remove
# Jelastic autoconfiguration markfrom/etc/httpd/conf/httpd.conf. - NGINX PHP: remove
; Jelastic autoconfiguration markfrom/etc/php-fpm.conf.
Save the modified configuration file after removing the marker.
Apache PHP Settings
Apache PHP handles requests with the prefork Multi-Processing Module. The related directives are stored in /etc/httpd/conf/httpd.conf.
The platform manages these prefork directives:
StartServersNumber of child server processes created during startup.MinSpareServers / MaxSpareServersMinimum and maximum number of idle processes kept ready.ServerLimitMaximum permitted value for MaxRequestWorkers.MaxRequestWorkersMaximum number of simultaneous requests.MaxConnectionsPerChildNumber of requests a child process can serve before it is replaced.
ServerLimit and MaxRequestWorkers are calculated using the lower value from RAM-based and CPU-based limits:
MaxRequestWorkers = ServerLimit =
min({containerRam} / 30 MiB, {coresCount} × 5)
- The RAM-based limit divides the container memory by 30 MiB.
- The CPU-based limit multiplies the available physical-core count by five.
- The lower result prevents the worker limit from exceeding available hardware capacity.
NGINX PHP Settings
NGINX PHP uses PHP FastCGI Process Manager. Its main settings are stored in /etc/php-fpm.conf, which is normally available in the file manager’s Favorites list.
The default process-management mode is ondemand. New worker processes are created when required and idle processes are removed.
pm.max_children— maximum number of child processes. It follows the CPU capacity available to the container and is not set below two.pm.process_idle_timeout— time before an idle process is terminated; the documented default is 60 seconds.
PHPFPM_MAX_CHILDREN environment variable can define pm.max_children explicitly without disabling the complete optimisation mechanism.
PHP-FPM communication uses a UNIX-domain socket instead of a TCP connection, reducing routing and networking overhead for processes running on the same host.
LiteSpeed and LLSMP
LiteSpeed stacks automatically optimise the worker-process count according to allocated RAM and CPU cores. The JELASTIC_AUTOCONFIG environment variable controls whether this optimisation is enabled.
true— enables auto-configuration and is the default.false— disables auto-configuration for manual tuning.
