You've just pushed a critical hotfix to your production server. You've checked the file via SSH, the code is definitely there, and you've cleared your browser cache. But when you refresh the page, the bug is still happening. It's like the server is hallucinating an older version of your code.

// I changed this from 10 to 100 to fix a pagination bug
$limit = 100; 
$results = $db->query("SELECT * FROM posts LIMIT $limit");

If you're seeing the old behavior despite the file being correct on disk, you've likely run into the most common "gotcha" with OPcache. I've spent a few hours of my life staring at a screen wondering why my changes weren't applying, only to realize the server was happily serving a compiled version of the script from shared memory, completely ignoring the actual file on the disk.

The Ghost in the Machine: Why Your Changes Aren't Showing

PHP is an interpreted language, but "interpreting" the same script 10,000 times a second is a waste of CPU. OPcache solves this by compiling your PHP code into "opcodes" and storing them in shared memory. The next time the script is requested, PHP skips the parsing and compilation phases and jumps straight to execution.

The problem occurs when opcache.validate_timestamps is set to 0. In high-performance production environments, we often turn this off because checking the file modification time on every single request—even if it's fast—adds up to significant disk I/O overhead. When it's off, OPcache assumes the code never changes until the cache is manually cleared or the server restarts.

To fix this during development or staging, you want opcache.validate_timestamps=1. If you're in production and can't restart the server, you can force a refresh using opcache_reset() in a temporary script, or by reloading the PHP-FPM service.

Tuning the Memory Buffer for Real Traffic

Getting OPcache "on" is easy. Getting it "right" is where the engineering happens. If you leave the defaults, you'll likely hit a wall as your application grows. The two biggest levers you have are memory consumption and the file limit.

• opcache.memory_consumption: This is the amount of RAM allocated to store the compiled scripts. If your app is huge (think a massive Laravel or Symfony install with hundreds of dependencies), the default 128MB might not be enough. When this fills up, PHP has to start evicting old scripts, which causes a performance dip.
• opcache.max_accelerated_files: This isn't about memory; it's about the number of slots in the hash table used to track files. If you have 10,000 PHP files in your vendor folder but this is set to 4,000, OPcache will stop caching new files once the limit is hit, even if you have plenty of RAM left.

I usually recommend setting max_accelerated_files to a prime number (like 16229 instead of 16000) to reduce hash collisions in the internal lookup table. It's a small tweak, but it's a professional touch that keeps things efficient.

Preventing Memory Exhaustion with Interned Strings

There's a lesser-known setting called opcache.interned_strings_buffer. In PHP, the same strings (like variable names or array keys) appear thousands of times across different files. Interning allows PHP to store one copy of a string and have every script point to that single memory address.

If you see "interned strings buffer is full" in your logs, your CPU will spike because PHP has to stop optimizing strings. Bumping this from the default 8MB to 16MB or 32MB is usually a safe bet for modern applications. It's a cheap way to shave a few more milliseconds off your response time.

📋 Practical Task

Audit and Optimize a Saturated OPcache Buffer

You are managing a legacy application with a massive number of dependencies. You suspect the OPcache is misconfigured because the server's CPU is spiking during peak traffic, and the logs indicate that the cache is constantly being cleared and refilled.

Your Task:

1. Write a PHP script that calls opcache_get_status(true) and prints the opcache_statistics array.
2. Analyze the output. Look specifically for the num_cached_scripts compared to the max_accelerated_files setting.
3. Assuming the output shows num_cached_scripts: 12000 and max_accelerated_files: 10000, identify exactly why the performance is degrading.
4. Write the specific php.ini configuration lines you would use to resolve this, ensuring you use a prime number for the file limit and increase the memory consumption to 256MB to handle the overhead.