Boost PHP Performance: Opcode Caching, php.ini Tweaks, and eAccelerator Guide

PHP Optimization

PHP is the engine that runs application code. Install only the modules you need and configure the web server to invoke PHP only for script files (typically *.php), not for all static files.

Opcode Cache

When a PHP script is requested, PHP reads it and compiles it to Zend opcode , a binary representation of the code. The opcode is executed and discarded. An opcode cache stores the compiled opcode for reuse, saving time. Several caches exist; eAccelerator is commonly used.

To install eAccelerator you need the PHP development libraries. Because file locations differ across Linux distributions, follow the installation instructions on the eAccelerator website. Some distributions already include an opcode cache that can be installed directly.

Configuration is typically in /etc/php.d/eaccelerator.ini. The eaccelerator.shm_size directive defines the shared memory cache size in megabytes; 64 MB is a reasonable default. If the value is rejected, increase the kernel’s maximum shared memory by adding kernel.shmmax=67108864 to /etc/sysctl.conf and applying with sysctl -p.

The eaccelerator.shm_ttl setting (default “60”) determines how long unused scripts remain in memory before being cleared when the cache is full.

Alternative tools include Alternative PHP Cache (APC) and Zend’s commercial opcode cache with an optimizer.

php.ini Resource Settings

Four important directives control how much system resources PHP may use:

max_execution_time – maximum CPU seconds a script may consume (recommended 30).

max_input_time – maximum seconds a script may wait for input data (recommended 60).

memory_limit – maximum memory a script may use before termination (recommended 32M).

output_buffering – number of bytes to buffer before sending data to the client (recommended 4096).

Adjust these values based on your application’s needs; large file uploads may require a higher max_input_time, and CPU‑ or memory‑intensive scripts may need larger limits. Note that max_execution_time measures CPU time, not wall‑clock time, so I/O‑heavy scripts can exceed it.

Log settings should be minimized in production; enabling only essential logs (e.g., error_reporting = E_COMPILE_ERROR|E_ERROR|E_CORE_ERROR) reduces disk writes while still surfacing critical issues.

Conclusion

The article focuses on web‑server tuning for Apache and PHP. For Apache, eliminate unnecessary checks such as processing .htaccess files and tune the multi‑processing module to balance resource usage and idle workers. For PHP, install an opcode cache and fine‑tune the resource directives to prevent scripts from wasting system resources or slowing other tasks.

The next and final article in the series will cover MySQL database tuning.