PHP and MySQL
PHP OPcache in production: what to tune
Use OPcache to avoid repeated PHP parsing while sizing memory and choosing safe code-change validation behaviour.
By AppLaunch Editorial · Reviewed 2026-08-25
Direct answer
OPcache stores compiled PHP bytecode in shared memory, removing repeated parse and compile work. Size it so the application fits without excessive restarts, keep timestamp validation aligned with the deployment model, and monitor cache fullness and wasted memory.
What this means in plain English
PHP normally has to read and prepare code files before running them. OPcache keeps the prepared version in memory so later requests can reuse it. This can make a busy PHP site faster without changing the application.
The cache needs enough room for the real codebase and a clear way to notice new files after deployment. Monitor whether it fills up or restarts often. OPcache cannot fix slow database queries or an overloaded external API.
What does OPcache improve?
| Memory | Enough for application scripts and interned strings |
|---|---|
| File capacity | max_accelerated_files exceeds real script count |
| Deployment | Invalidate or restart cache predictably when code changes |
A simple example
A site has 12,000 PHP files but the cache is set to hold fewer. Files keep dropping out and being prepared again. Increasing the file capacity based on the measured codebase improves the hit rate, while the deployment process resets the cache when code changes.
What to do, step by step
1. Count PHP files and inspect current OPcache status.
Start here before buying anything or changing several settings at once. It gives you a clear starting point based on memory: enough for application scripts and interned strings. Write the result down so you can compare it later.
2. Choose memory from measured usage.
Use the same files, versions and settings that the real project will use. A quick test with an empty or different setup can look successful while completely missing the problem you are trying to solve.
3. Define cache reset as part of deployment.
Try the busiest realistic situation, not the easiest one. Include the people, data, traffic or background work you genuinely expect, then watch for slowdowns and errors rather than relying on a single headline number.
4. Compare request latency and cache hit rate.
Finish by checking the result against deployment: invalidate or restart cache predictably when code changes. Keep the old setting or release available until you know the change works and can be reversed safely.
One more useful tip
Development and production often need different change-detection settings. Developers want edits to appear immediately; production wants predictable fast releases with an explicit cache refresh.
Common mistakes and how to avoid them
Disabling timestamp checks without a deploy reset.
This gives a misleading or unsafe result because it leaves out memory. A better approach is to count php files and inspect current opcache status, then check the result before making the change permanent.
Copying old tuning values blindly.
This gives a misleading or unsafe result because it leaves out file capacity. A better approach is to choose memory from measured usage, then check the result before making the change permanent.
Expecting OPcache to fix slow database queries.
This gives a misleading or unsafe result because it leaves out deployment. A better approach is to define cache reset as part of deployment, then check the result before making the change permanent.
Words explained
- PHP
- The programming language that runs the server-side part of many websites and applications.
- OPcache
- A PHP feature that keeps already-compiled code in memory so PHP does not have to prepare the same files on every request.
Quick checklist
- Count PHP files and inspect current OPcache status.
- Choose memory from measured usage.
- Define cache reset as part of deployment.
- Compare request latency and cache hit rate.
Common questions
What is the simple answer?
OPcache stores compiled PHP bytecode in shared memory, removing repeated parse and compile work. Size it so the application fits without excessive restarts, keep timestamp validation aligned with the deployment model, and monitor cache fullness and wasted memory.
What should I check first?
Start with memory: enough for application scripts and interned strings. That is usually more useful than choosing from a marketing label or copying somebody else’s setting.
How can I make the change safely?
Count PHP files and inspect current OPcache status. Then change one thing at a time, keep a backup or old version, and use the same real-world test after each change.
What is the easiest mistake to avoid?
Disabling timestamp checks without a deploy reset. Avoiding that one mistake makes the rest of the comparison much more trustworthy.