{"id":3722,"date":"2025-12-30T13:20:47","date_gmt":"2025-12-30T10:20:47","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/php-opcache-settings-best-configuration-for-wordpress-laravel-and-woocommerce\/"},"modified":"2025-12-30T13:20:47","modified_gmt":"2025-12-30T10:20:47","slug":"php-opcache-settings-best-configuration-for-wordpress-laravel-and-woocommerce","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/php-opcache-settings-best-configuration-for-wordpress-laravel-and-woocommerce\/","title":{"rendered":"PHP OPcache Settings: Best Configuration for WordPress, Laravel and WooCommerce"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>PHP OPcache is one of the easiest performance wins you can get for WordPress, Laravel and WooCommerce, yet on many servers it is either misconfigured or barely used. When we tune new environments at dchost.com, OPcache is always in the first batch of settings we review \u2013 right after PHP-FPM and basic PHP limits. A few lines in php.ini can cut CPU usage dramatically, lower TTFB and make heavy dashboards feel much more responsive. In this guide we will walk through practical OPcache settings that work well in real WordPress, Laravel and WooCommerce projects, explain what each directive does in plain language, and share configuration examples you can paste into your own server (and then fine\u2011tune). Whether you are on shared hosting, an NVMe <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a> or a <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a>, you will leave with a clear template for safe, fast OPcache configuration that plays nicely with your deployment workflow.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#What_PHP_OPcache_Really_Does_for_Your_PHP_Apps\"><span class=\"toc_number toc_depth_1\">1<\/span> What PHP OPcache Really Does for Your PHP Apps<\/a><\/li><li><a href=\"#OPcache_MustHave_Settings_The_Short_Version\"><span class=\"toc_number toc_depth_1\">2<\/span> OPcache Must\u2011Have Settings: The Short Version<\/a><\/li><li><a href=\"#Understanding_Key_OPcache_Directives_One_by_One\"><span class=\"toc_number toc_depth_1\">3<\/span> Understanding Key OPcache Directives One by One<\/a><ul><li><a href=\"#opcacheenable_and_opcacheenable_cli\"><span class=\"toc_number toc_depth_2\">3.1<\/span> opcache.enable and opcache.enable_cli<\/a><\/li><li><a href=\"#opcachememory_consumption\"><span class=\"toc_number toc_depth_2\">3.2<\/span> opcache.memory_consumption<\/a><\/li><li><a href=\"#opcacheinterned_strings_buffer\"><span class=\"toc_number toc_depth_2\">3.3<\/span> opcache.interned_strings_buffer<\/a><\/li><li><a href=\"#opcachemax_accelerated_files\"><span class=\"toc_number toc_depth_2\">3.4<\/span> opcache.max_accelerated_files<\/a><\/li><li><a href=\"#validate_timestamps_and_revalidate_freq\"><span class=\"toc_number toc_depth_2\">3.5<\/span> validate_timestamps and revalidate_freq<\/a><\/li><li><a href=\"#opcachemax_wasted_percentage\"><span class=\"toc_number toc_depth_2\">3.6<\/span> opcache.max_wasted_percentage<\/a><\/li><li><a href=\"#opcachesave_comments\"><span class=\"toc_number toc_depth_2\">3.7<\/span> opcache.save_comments<\/a><\/li><li><a href=\"#opcachefile_update_protection\"><span class=\"toc_number toc_depth_2\">3.8<\/span> opcache.file_update_protection<\/a><\/li><li><a href=\"#opcacherestrict_api\"><span class=\"toc_number toc_depth_2\">3.9<\/span> opcache.restrict_api<\/a><\/li><li><a href=\"#JIT_opcachejit_and_opcachejit_buffer_size\"><span class=\"toc_number toc_depth_2\">3.10<\/span> JIT: opcache.jit and opcache.jit_buffer_size<\/a><\/li><\/ul><\/li><li><a href=\"#Recommended_OPcache_Configurations_by_Stack\"><span class=\"toc_number toc_depth_1\">4<\/span> Recommended OPcache Configurations by Stack<\/a><ul><li><a href=\"#1_WordPress_WooCommerce_on_Shared_Hosting\"><span class=\"toc_number toc_depth_2\">4.1<\/span> 1) WordPress &amp; WooCommerce on Shared Hosting<\/a><\/li><li><a href=\"#2_WordPress_WooCommerce_on_a_VPS_or_Dedicated_Server\"><span class=\"toc_number toc_depth_2\">4.2<\/span> 2) WordPress &amp; WooCommerce on a VPS or Dedicated Server<\/a><\/li><li><a href=\"#3_Laravel_on_a_VPS_or_Dedicated_Server\"><span class=\"toc_number toc_depth_2\">4.3<\/span> 3) Laravel on a VPS or Dedicated Server<\/a><\/li><\/ul><\/li><li><a href=\"#How_OPcache_Interacts_with_PHPFPM_JIT_and_Application_Caches\"><span class=\"toc_number toc_depth_1\">5<\/span> How OPcache Interacts with PHP\u2011FPM, JIT and Application Caches<\/a><ul><li><a href=\"#OPcache_and_PHPFPM_Pools\"><span class=\"toc_number toc_depth_2\">5.1<\/span> OPcache and PHP\u2011FPM Pools<\/a><\/li><li><a href=\"#OPcache_vs_Object_Cache_RedisMemcached\"><span class=\"toc_number toc_depth_2\">5.2<\/span> OPcache vs Object Cache (Redis\/Memcached)<\/a><\/li><li><a href=\"#OPcache_and_JIT_in_Real_Projects\"><span class=\"toc_number toc_depth_2\">5.3<\/span> OPcache and JIT in Real Projects<\/a><\/li><\/ul><\/li><li><a href=\"#Monitoring_and_Debugging_OPcache_in_Production\"><span class=\"toc_number toc_depth_1\">6<\/span> Monitoring and Debugging OPcache in Production<\/a><ul><li><a href=\"#Checking_OPcache_Status_from_CLI\"><span class=\"toc_number toc_depth_2\">6.1<\/span> Checking OPcache Status from CLI<\/a><\/li><li><a href=\"#Common_OPcacheRelated_Issues\"><span class=\"toc_number toc_depth_2\">6.2<\/span> Common OPcache\u2011Related Issues<\/a><\/li><li><a href=\"#Small_OPcache_Status_Dashboard\"><span class=\"toc_number toc_depth_2\">6.3<\/span> Small OPcache Status Dashboard<\/a><\/li><\/ul><\/li><li><a href=\"#Safe_Deployment_Workflow_with_OPcache_Enabled\"><span class=\"toc_number toc_depth_1\">7<\/span> Safe Deployment Workflow with OPcache Enabled<\/a><\/li><li><a href=\"#Putting_It_All_Together_Practical_Checklists\"><span class=\"toc_number toc_depth_1\">8<\/span> Putting It All Together: Practical Checklists<\/a><ul><li><a href=\"#Checklist_for_WordPress_WooCommerce\"><span class=\"toc_number toc_depth_2\">8.1<\/span> Checklist for WordPress \/ WooCommerce<\/a><\/li><li><a href=\"#Checklist_for_Laravel\"><span class=\"toc_number toc_depth_2\">8.2<\/span> Checklist for Laravel<\/a><\/li><\/ul><\/li><li><a href=\"#Final_Thoughts_and_Next_Steps\"><span class=\"toc_number toc_depth_1\">9<\/span> Final Thoughts and Next Steps<\/a><\/li><\/ul><\/div>\n<h2><span id=\"What_PHP_OPcache_Really_Does_for_Your_PHP_Apps\">What PHP OPcache Really Does for Your PHP Apps<\/span><\/h2>\n<p>Every time PHP executes a file, it first needs to read the source code, parse it and compile it into opcode (machine\u2011readable instructions). Without OPcache, this happens on every request. OPcache stores the compiled opcode in memory so the next request can reuse it instantly instead of recompiling. That means:<\/p>\n<ul>\n<li>Less CPU time spent compiling PHP files<\/li>\n<li>Lower request latency, especially under load<\/li>\n<li>More capacity from the same hardware<\/li>\n<\/ul>\n<p>For WordPress and WooCommerce, this mostly accelerates core, plugin and theme PHP files. For Laravel, it speeds up framework classes, your application code and vendor libraries. OPcache is not a replacement for object cache (Redis\/Memcached) or full\u2011page caching, but it is the base layer. In fact, it works best when combined with the techniques we covered in <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-icin-sunucu-tarafi-optimizasyon-php-fpm-opcache-redis-ve-mysql-ile-neyi-ne-zaman-nasil-ayarlamalisin\/\">our server\u2011side optimization guide for WordPress (PHP\u2011FPM, OPcache, Redis and MySQL tuning)<\/a>.<\/p>\n<h2><span id=\"OPcache_MustHave_Settings_The_Short_Version\">OPcache Must\u2011Have Settings: The Short Version<\/span><\/h2>\n<p>Before diving deep, here is a practical baseline we frequently use on PHP 8.x for WordPress, WooCommerce and Laravel on a typical VPS (2\u20134 vCPU, 4\u20138 GB RAM):<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">; Enable OPcache\nopcache.enable=1\nopcache.enable_cli=0\n\n; Memory and file capacity\nopcache.memory_consumption=256\nopcache.interned_strings_buffer=16\nopcache.max_accelerated_files=20000\nopcache.max_wasted_percentage=5\n\n; File change detection (for shared hosting \/ simple setups)\nopcache.validate_timestamps=1\nopcache.revalidate_freq=60\n\n; Safer behavior\nopcache.save_comments=1\nopcache.fast_shutdown=1\nopcache.enable_file_override=1\n\n; JIT (optional, usually OFF for classic WordPress\/WooCommerce)\nopcache.jit=0\nopcache.jit_buffer_size=0\n<\/code><\/pre>\n<p>You will tune these numbers depending on:<\/p>\n<ul>\n<li>PHP version (7.4 vs 8.1 vs 8.2+)<\/li>\n<li>Project size (number of PHP files, plugins, Composer packages)<\/li>\n<li>Server RAM<\/li>\n<li>Deployment workflow (manual FTP vs automated CI\/CD)<\/li>\n<\/ul>\n<p>Next, we will go directive by directive and then build tailored configs for WordPress, Laravel and WooCommerce.<\/p>\n<h2><span id=\"Understanding_Key_OPcache_Directives_One_by_One\">Understanding Key OPcache Directives One by One<\/span><\/h2>\n<h3><span id=\"opcacheenable_and_opcacheenable_cli\">opcache.enable and opcache.enable_cli<\/span><\/h3>\n<p><strong>opcache.enable<\/strong> turns OPcache on for web SAPI (PHP\u2011FPM, mod_php, etc.). This should almost always be <strong>1<\/strong> on production servers.<\/p>\n<p><strong>opcache.enable_cli<\/strong> controls OPcache for the PHP CLI (command line). You may want OPcache disabled for CLI on small servers to avoid extra memory usage, but there are also good reasons to keep it enabled for Laravel <code>artisan<\/code> commands or long\u2011running CLI tools.<\/p>\n<ul>\n<li><strong>Shared hosting \/ small VPS:<\/strong> <code>opcache.enable_cli=0<\/code><\/li>\n<li><strong>Large Laravel projects with heavy CLI usage:<\/strong> consider <code>opcache.enable_cli=1<\/code><\/li>\n<\/ul>\n<h3><span id=\"opcachememory_consumption\">opcache.memory_consumption<\/span><\/h3>\n<p>This sets how much shared memory (in MB) OPcache can use to store compiled PHP code. If this is too low, OPcache fills up quickly, starts evicting old scripts and you lose most of the benefit.<\/p>\n<ul>\n<li><strong>Small WordPress sites (few plugins):<\/strong> 64\u2013128 MB<\/li>\n<li><strong>WooCommerce \/ multiple plugins:<\/strong> 192\u2013256 MB<\/li>\n<li><strong>Medium Laravel apps with many Composer deps:<\/strong> 256\u2013512 MB<\/li>\n<li><strong>Very large multi\u2011tenant or monorepo apps:<\/strong> 512 MB+<\/li>\n<\/ul>\n<p>On a server with 4\u20138 GB RAM, allocating 256 MB to OPcache is usually a safe starting point. Watch usage over time and increase if fragmentation grows or hit rate falls.<\/p>\n<h3><span id=\"opcacheinterned_strings_buffer\">opcache.interned_strings_buffer<\/span><\/h3>\n<p>PHP can &#8220;intern&#8221; strings \u2013 store a single copy in memory and reuse it \u2013 which reduces memory usage and speeds comparisons. <strong>opcache.interned_strings_buffer<\/strong> controls how many megabytes are available for those interned strings.<\/p>\n<ul>\n<li><strong>Default is often too low<\/strong> (e.g. 8 MB).<\/li>\n<li>For modern frameworks and plugin\u2011heavy WordPress, <strong>16\u201332 MB<\/strong> is a better target.<\/li>\n<\/ul>\n<p>We commonly use:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">opcache.interned_strings_buffer=16<\/code><\/pre>\n<p>and go up to 32 MB on large Laravel microservice clusters with many shared libraries.<\/p>\n<h3><span id=\"opcachemax_accelerated_files\">opcache.max_accelerated_files<\/span><\/h3>\n<p>This is the maximum number of PHP scripts that OPcache can keep track of. Each file stored in OPcache occupies a slot. If the limit is lower than the number of distinct PHP files your app uses, older entries will get dropped frequently.<\/p>\n<p>Rules of thumb:<\/p>\n<ul>\n<li><strong>Small WordPress sites:<\/strong> 8000\u201310000<\/li>\n<li><strong>WooCommerce + many plugins:<\/strong> 20000<\/li>\n<li><strong>Medium\u2013large Laravel apps:<\/strong> 20000\u201340000<\/li>\n<\/ul>\n<p>On modern hardware, setting this higher (e.g. 20000) is usually safe and cheap in terms of memory.<\/p>\n<h3><span id=\"validate_timestamps_and_revalidate_freq\">validate_timestamps and revalidate_freq<\/span><\/h3>\n<p>These two settings control how OPcache notices file changes:<\/p>\n<ul>\n<li><strong>opcache.validate_timestamps<\/strong> \u2013 if 1, PHP checks file modification times periodically; if 0, it never checks (until restart or manual reset).<\/li>\n<li><strong>opcache.revalidate_freq<\/strong> \u2013 how often (in seconds) it checks timestamps.<\/li>\n<\/ul>\n<p>On shared hosting or any environment where files can change at random times (manual FTP, plugin uploads via dashboard), you should keep <strong>validate_timestamps=1<\/strong>.<\/p>\n<p>Recommended patterns:<\/p>\n<ul>\n<li><strong>Shared hosting WordPress:<\/strong> <code>opcache.validate_timestamps=1<\/code>, <code>opcache.revalidate_freq=60<\/code><\/li>\n<li><strong>VPS with simple manual deploys:<\/strong> <code>revalidate_freq=30\u201360<\/code><\/li>\n<li><strong>CI\/CD with atomic releases:<\/strong> you can set <code>validate_timestamps=0<\/code> and call <code>opcache_reset()<\/code> or reload PHP\u2011FPM on each deploy for maximum performance.<\/li>\n<\/ul>\n<p>If you are moving towards zero\u2011downtime deployments, the patterns in our guides on <a href=\"https:\/\/www.dchost.com\/blog\/en\/vpse-sifir-kesinti-ci-cd-nasil-kurulur-rsync-sembolik-surumler-ve-systemd-ile-sicacik-bir-yolculuk\/\">zero\u2011downtime CI\/CD to a VPS with rsync + symlinks<\/a> and <a href=\"https:\/\/www.dchost.com\/blog\/en\/laravel-uygulamalarini-vpste-nasil-yayinlarim-nginx-php%E2%80%91fpm-horizon-ve-sifir-kesinti-dagitimin-sicacik-yol-haritasi\/\">deploying Laravel on a VPS with truly zero\u2011downtime releases<\/a> fit nicely with <code>validate_timestamps=0<\/code>.<\/p>\n<h3><span id=\"opcachemax_wasted_percentage\">opcache.max_wasted_percentage<\/span><\/h3>\n<p>OPcache memory can become fragmented over time as scripts are added and removed. <strong>opcache.max_wasted_percentage<\/strong> sets the threshold at which OPcache will restart itself to defragment memory.<\/p>\n<p>A value of <strong>5\u201310<\/strong> is common:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">opcache.max_wasted_percentage=5<\/code><\/pre>\n<p>Lower values keep fragmentation under tighter control but may trigger more frequent restarts. For most real\u2011world WordPress and Laravel apps, 5% is a good balance.<\/p>\n<h3><span id=\"opcachesave_comments\">opcache.save_comments<\/span><\/h3>\n<p>Some frameworks and tools rely on PHP doc comments (for annotations, attributes discovery, etc.). <strong>opcache.save_comments<\/strong> chooses whether OPcache keeps these comments.<\/p>\n<ul>\n<li><strong>1 (recommended):<\/strong> keep comments, full compatibility<\/li>\n<li><strong>0:<\/strong> slightly less memory usage, but can break frameworks or tools that inspect docblocks<\/li>\n<\/ul>\n<p>Because WordPress plugins and Laravel packages may rely on annotations, we strongly recommend:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">opcache.save_comments=1<\/code><\/pre>\n<h3><span id=\"opcachefile_update_protection\">opcache.file_update_protection<\/span><\/h3>\n<p>This setting adds a delay (seconds) to avoid caching files that are actively being written (useful with slow NFS or network filesystems). On typical local SSD\/NVMe hosting, you can keep it small or even 0.<\/p>\n<ul>\n<li><strong>Local disks (typical VPS \/ dedicated):<\/strong> <code>opcache.file_update_protection=0<\/code><\/li>\n<li><strong>Remote filesystems:<\/strong> keep default (2) or increase slightly if you see corrupted caches on deploy<\/li>\n<\/ul>\n<h3><span id=\"opcacherestrict_api\">opcache.restrict_api<\/span><\/h3>\n<p>This optional setting lets you restrict OPcache API functions (<code>opcache_reset<\/code>, <code>opcache_invalidate<\/code>, etc.) to scripts in a specific directory. It is useful if you want a deployment script to control OPcache but do not want arbitrary PHP code calling these functions.<\/p>\n<p>Example:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">opcache.restrict_api=&quot;\/var\/www\/deploy-scripts&quot;<\/code><\/pre>\n<h3><span id=\"JIT_opcachejit_and_opcachejit_buffer_size\">JIT: opcache.jit and opcache.jit_buffer_size<\/span><\/h3>\n<p>PHP 8 introduced JIT (Just\u2011In\u2011Time compilation) as part of OPcache. JIT can speed up CPU\u2011heavy numeric or algorithmic workloads, but for typical WordPress and WooCommerce sites it often brings little benefit and sometimes complicates debugging.<\/p>\n<ul>\n<li><strong>Classic WordPress \/ WooCommerce:<\/strong> safe to keep JIT disabled:<\/li>\n<\/ul>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">opcache.jit=0\nopcache.jit_buffer_size=0<\/code><\/pre>\n<ul>\n<li><strong>Laravel APIs with heavy CPU work (image processing, complex calculations):<\/strong> JIT <em>might<\/em> help, but test carefully with benchmarks and monitoring before turning it on across the board.<\/li>\n<\/ul>\n<p>If you plan a broader PHP 8.x tuning project, our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/php-8-x-yukseltme-kontrol-listesi-wordpress-ve-laravelde-geriye-uyumluluk-opcache-preload-ve-fpm-havuz-ayarlari-nasil-tatli-tatli-kurulur\/\">the PHP 8.x upgrade checklist (OPcache preload and FPM pool tuning)<\/a> gives a wider context.<\/p>\n<h2><span id=\"Recommended_OPcache_Configurations_by_Stack\">Recommended OPcache Configurations by Stack<\/span><\/h2>\n<h3><span id=\"1_WordPress_WooCommerce_on_Shared_Hosting\">1) WordPress &amp; WooCommerce on Shared Hosting<\/span><\/h3>\n<p>On shared hosting, you usually <em>cannot<\/em> edit the global php.ini, but you might control per\u2011user overrides through <code>.user.ini<\/code> or a control panel. You also have less RAM, and many users share the same PHP instance.<\/p>\n<p>In this environment, keep OPcache conservative and compatibility\u2011focused:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">; Enable OPcache for web only\nopcache.enable=1\nopcache.enable_cli=0\n\n; Modest memory for many small sites\nopcache.memory_consumption=128\nopcache.interned_strings_buffer=8\nopcache.max_accelerated_files=10000\nopcache.max_wasted_percentage=10\n\n; Always check for file changes periodically\nopcache.validate_timestamps=1\nopcache.revalidate_freq=60\nopcache.file_update_protection=2\n\n; Safer defaults\nopcache.save_comments=1\nopcache.fast_shutdown=1\nopcache.enable_file_override=1\n\n; JIT off\nopcache.jit=0\nopcache.jit_buffer_size=0<\/code><\/pre>\n<p>You will not have full control over all values on most shared plans, but understanding these directives helps you read the hosting provider\u2019s defaults and decide when it is time to move resource\u2011hungry stores to a VPS. If you frequently hit &#8220;Resource Limit Reached&#8221; or see high TTFB during campaigns, combine OPcache tuning with the strategies in our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/paylasimli-hostingden-vpse-sorunsuz-gecis-rehberi\/\">moving from shared hosting to a VPS without downtime<\/a>.<\/p>\n<h3><span id=\"2_WordPress_WooCommerce_on_a_VPS_or_Dedicated_Server\">2) WordPress &amp; WooCommerce on a VPS or Dedicated Server<\/span><\/h3>\n<p>Once you control your own PHP\u2011FPM pools and php.ini, you can allocate more memory to OPcache and tighten timestamp checks. For a typical 2\u20134 vCPU, 4\u20138 GB RAM NVMe VPS hosting a few WordPress and WooCommerce sites, we often start with:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">opcache.enable=1\nopcache.enable_cli=0\n\n; More generous memory\nopcache.memory_consumption=256\nopcache.interned_strings_buffer=16\nopcache.max_accelerated_files=20000\nopcache.max_wasted_percentage=5\n\n; File change detection\n; If you deploy via git\/rsync and control releases, you can reduce checks\nopcache.validate_timestamps=1\nopcache.revalidate_freq=30\nopcache.file_update_protection=0\n\nopcache.save_comments=1\nopcache.fast_shutdown=1\nopcache.enable_file_override=1\n\n; JIT disabled for typical WooCommerce\nopcache.jit=0\nopcache.jit_buffer_size=0<\/code><\/pre>\n<p>On multi\u2011tenant VPS setups where each site has its own PHP\u2011FPM pool (as we often design for agencies), make sure OPcache memory per pool plus PHP <code>memory_limit<\/code> and FPM settings still fit into total RAM. Our post on <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-ve-woocommerce-icin-php-fpm-ayarlari-pm-pm-max_children-ve-pm-max_requests-hesaplama-rehberi\/\">PHP\u2011FPM settings for WordPress and WooCommerce (pm and max_children calculation)<\/a> is a good companion when you size everything together.<\/p>\n<h3><span id=\"3_Laravel_on_a_VPS_or_Dedicated_Server\">3) Laravel on a VPS or Dedicated Server<\/span><\/h3>\n<p>Laravel applications tend to have more PHP files (framework + vendor + app code), so we usually raise <code>max_accelerated_files<\/code> and consider a slightly larger <code>memory_consumption<\/code>.<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">opcache.enable=1\n; Decide per project whether CLI caching is useful\nopcache.enable_cli=0\n\nopcache.memory_consumption=256 ; or 512 for large apps\nopcache.interned_strings_buffer=16\nopcache.max_accelerated_files=40000\nopcache.max_wasted_percentage=5\n\n; With proper deploys, you can disable timestamp validation\nopcache.validate_timestamps=0\nopcache.revalidate_freq=0\nopcache.file_update_protection=0\n\nopcache.save_comments=1\nopcache.fast_shutdown=1\nopcache.enable_file_override=1\n\n; JIT off unless you tested and measured benefits\nopcache.jit=0\nopcache.jit_buffer_size=0<\/code><\/pre>\n<p>With <code>validate_timestamps=0<\/code>, you <strong>must<\/strong> integrate an OPcache reset into your deployment pipeline. Typical patterns:<\/p>\n<ul>\n<li>Reload PHP\u2011FPM: <code>systemctl reload php-fpm<\/code> (or pool\u2011specific reload)<\/li>\n<li>Call a small, protected script that runs <code>opcache_reset()<\/code> after a new release is symlinked<\/li>\n<\/ul>\n<p>This aligns nicely with the production tune\u2011up we describe in <a href=\"https:\/\/www.dchost.com\/blog\/en\/laravel-prod-ortam-optimizasyonu-nasil-yapilir-php%E2%80%91fpm-opcache-octane-queue-horizon-ve-redisi-el-ele-calistirmak\/\">our Laravel production optimization guide (PHP\u2011FPM pools, OPcache, Octane, queues and Redis)<\/a>.<\/p>\n<h2><span id=\"How_OPcache_Interacts_with_PHPFPM_JIT_and_Application_Caches\">How OPcache Interacts with PHP\u2011FPM, JIT and Application Caches<\/span><\/h2>\n<h3><span id=\"OPcache_and_PHPFPM_Pools\">OPcache and PHP\u2011FPM Pools<\/span><\/h3>\n<p>On most Linux servers, OPcache runs in shared memory per PHP\u2011FPM master process. Each pool shares the same OPcache instance by default. That means:<\/p>\n<ul>\n<li>Raising <code>opcache.memory_consumption<\/code> increases shared memory for <em>all<\/em> pools<\/li>\n<li>Reloading PHP\u2011FPM clears OPcache (all scripts are recompiled on first use)<\/li>\n<\/ul>\n<p>When designing multi\u2011tenant hosting (many sites, one server), combine OPcache sizing with PHP\u2011FPM limits and PHP <code>memory_limit<\/code>. If a WooCommerce site uses 512 MB of PHP memory per request and you allow many FPM children, OPcache memory becomes relatively small in that picture. The balance across OPcache, <code>memory_limit<\/code> and process counts is often more impactful than any single directive.<\/p>\n<h3><span id=\"OPcache_vs_Object_Cache_RedisMemcached\">OPcache vs Object Cache (Redis\/Memcached)<\/span><\/h3>\n<p>OPcache stores compiled PHP code. Object caches store application data (e.g. query results, options, session data). Both are important but solve different problems.<\/p>\n<ul>\n<li>OPcache reduces CPU time spent parsing and compiling PHP<\/li>\n<li>Object cache reduces database queries and expensive computations<\/li>\n<\/ul>\n<p>For serious WooCommerce or Laravel apps, you usually want both. To understand the data\u2011side caching piece better, you can read our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/php-session-ve-cache-depolamasini-dogru-secmek-dosya-redis-ve-memcachedin-wordpress-ve-laravel-performansina-etkisi\/\">choosing PHP session and cache storage (files vs Redis vs Memcached)<\/a> and our detailed <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpresste-redis-memcached-object-cache-kurulumu\/\">WordPress object cache setup with Redis or Memcached<\/a>.<\/p>\n<h3><span id=\"OPcache_and_JIT_in_Real_Projects\">OPcache and JIT in Real Projects<\/span><\/h3>\n<p>For 90% of WordPress and WooCommerce sites we see, JIT is not the bottleneck: disk I\/O, database performance, slow plugins and network latency come first. JIT also adds moving parts for debugging and memory usage. In most e\u2011commerce and content sites, we prefer:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">opcache.jit=0\nopcache.jit_buffer_size=0<\/code><\/pre>\n<p>For compute\u2011heavy Laravel workloads, test JIT in a staging environment with realistic load tests (for example, using the techniques described in our article about <a href=\"https:\/\/www.dchost.com\/blog\/en\/trafik-patlamasindan-once-load-test-yapmak-k6-jmeter-ve-locust-ile-kapasite-olcme-rehberi\/\">load testing hosting with k6, JMeter and Locust<\/a>). If you see a clear, reproducible gain and stable behavior, you can enable it selectively.<\/p>\n<h2><span id=\"Monitoring_and_Debugging_OPcache_in_Production\">Monitoring and Debugging OPcache in Production<\/span><\/h2>\n<h3><span id=\"Checking_OPcache_Status_from_CLI\">Checking OPcache Status from CLI<\/span><\/h3>\n<p>Start by confirming that OPcache is actually enabled and using the settings you expect. On the server:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">php -i | grep -i opcache<\/code><\/pre>\n<p>or create a small script:<\/p>\n<pre class=\"language-php line-numbers\"><code class=\"language-php\">&lt;?php\nprint_r(opcache_get_status());<\/code><\/pre>\n<p>Useful fields to watch:<\/p>\n<ul>\n<li><strong>memory_usage<\/strong> \u2013 how much of OPcache memory is used\/free<\/li>\n<li><strong>interned_strings_usage<\/strong> \u2013 interned string memory usage<\/li>\n<li><strong>opcache_statistics<\/strong> \u2013 hit rate, number of cached scripts, misses<\/li>\n<\/ul>\n<p>Ideal situation: high hit rate (&gt; 99%), low fragmentation, and plenty of free memory headroom. If you see OPcache memory constantly full, raise <code>memory_consumption<\/code> and\/or <code>max_accelerated_files<\/code> (if RAM allows).<\/p>\n<h3><span id=\"Common_OPcacheRelated_Issues\">Common OPcache\u2011Related Issues<\/span><\/h3>\n<ul>\n<li><strong>Code changes not visible:<\/strong> On servers with <code>validate_timestamps=0<\/code>, you must reload PHP\u2011FPM or call <code>opcache_reset()<\/code> after deploys.<\/li>\n<li><strong>Random old code after a failed deploy:<\/strong> If your deploy partially uploads files and OPcache caches them mid\u2011upload, you can end up with mixed versions. Use atomic deploys (symlink switch) and set <code>file_update_protection=0<\/code> on local storage.<\/li>\n<li><strong>High CPU spikes despite OPcache:<\/strong> Often due to database problems, missing object cache, or poor PHP\u2011FPM tuning rather than OPcache itself. Combine OPcache tuning with broader server optimization.<\/li>\n<\/ul>\n<h3><span id=\"Small_OPcache_Status_Dashboard\">Small OPcache Status Dashboard<\/span><\/h3>\n<p>For teams that prefer a visual overview, you can adapt a small, password\u2011protected dashboard page that calls <code>opcache_get_status()<\/code> and renders key metrics. Just make sure it is not publicly accessible, as it can leak path and environment information.<\/p>\n<h2><span id=\"Safe_Deployment_Workflow_with_OPcache_Enabled\">Safe Deployment Workflow with OPcache Enabled<\/span><\/h2>\n<p>Misaligned deployment and OPcache settings are a common source of &#8220;it works on some requests but not others&#8221; problems. A robust workflow usually follows these principles:<\/p>\n<ol>\n<li><strong>Build\/compile assets elsewhere<\/strong> (CI, local) so production only receives ready\u2011to\u2011run PHP and static files.<\/li>\n<li><strong>Deploy to a new release directory<\/strong>, e.g. <code>\/var\/www\/myapp\/releases\/2025-01-01-120000<\/code>.<\/li>\n<li><strong>Update a symlink<\/strong>, e.g. <code>\/var\/www\/myapp\/current<\/code> \u2192 new release, atomically.<\/li>\n<li><strong>Reload PHP\u2011FPM<\/strong> or call <code>opcache_reset()<\/code> after the symlink switch.<\/li>\n<\/ol>\n<p>With this approach, you can safely run with <code>validate_timestamps=0<\/code> and minimize filesystem checks on each request. It also integrates nicely with zero\u2011downtime techniques like phased FPM reloads and canary deployments. We use a similar pattern in our guides on <a href=\"https:\/\/www.dchost.com\/blog\/en\/vpse-sifir-kesinti-ci-cd-nasil-kurulur-rsync-sembolik-surumler-ve-systemd-ile-sicacik-bir-yolculuk\/\">zero\u2011downtime CI\/CD to a VPS<\/a> and <a href=\"https:\/\/www.dchost.com\/blog\/en\/laravel-uygulamalarini-vpste-nasil-yayinlarim-nginx-php%E2%80%91fpm-horizon-ve-sifir-kesinti-dagitimin-sicacik-yol-haritasi\/\">Laravel deployments with Nginx, PHP\u2011FPM and Horizon<\/a>.<\/p>\n<h2><span id=\"Putting_It_All_Together_Practical_Checklists\">Putting It All Together: Practical Checklists<\/span><\/h2>\n<h3><span id=\"Checklist_for_WordPress_WooCommerce\">Checklist for WordPress \/ WooCommerce<\/span><\/h3>\n<ul>\n<li>Ensure <code>opcache.enable=1<\/code> on all PHP\u2011FPM pools used by your sites<\/li>\n<li>Set <code>memory_consumption<\/code> to at least 128 MB (256 MB for larger stores)<\/li>\n<li>Set <code>max_accelerated_files<\/code> to at least 10000 (20000 for WooCommerce + many plugins)<\/li>\n<li>Keep <code>save_comments=1<\/code> to avoid breaking plugins relying on annotations<\/li>\n<li>On shared hosting: <code>validate_timestamps=1<\/code>, <code>revalidate_freq=60<\/code><\/li>\n<li>On VPS\/dedicated with controlled deploys: consider <code>validate_timestamps=0<\/code> + explicit <code>opcache_reset()<\/code> on release<\/li>\n<li>Keep JIT off unless you have a clear, tested reason to enable it<\/li>\n<\/ul>\n<h3><span id=\"Checklist_for_Laravel\">Checklist for Laravel<\/span><\/h3>\n<ul>\n<li>Raise <code>max_accelerated_files<\/code> (20000\u201340000) to fit framework + vendor + app files<\/li>\n<li>Start with 256\u2013512 MB <code>memory_consumption<\/code> on mid\u2011sized apps<\/li>\n<li>Disable timestamp validation and rely on atomic deploy + <code>opcache_reset()<\/code> when you have CI\/CD in place<\/li>\n<li>Keep <code>save_comments=1<\/code> for annotation\u2011heavy packages<\/li>\n<li>Evaluate whether <code>enable_cli<\/code> needs to be 1 for heavy <code>artisan<\/code> workflows<\/li>\n<li>Benchmark JIT only for CPU\u2011bound tasks; leave it off for standard CRUD APIs<\/li>\n<\/ul>\n<h2><span id=\"Final_Thoughts_and_Next_Steps\">Final Thoughts and Next Steps<\/span><\/h2>\n<p>OPcache is one of those settings that quietly pays off every single day once it is correctly tuned. For WordPress, WooCommerce and Laravel, the right configuration can shave precious milliseconds from each request, reduce CPU load during peak campaigns and give you more breathing room before you need to scale up hardware. The key is to treat OPcache as part of a broader stack: aligned with PHP\u2011FPM pools, PHP memory limits, database tuning and, when needed, Redis or Memcached caches.<\/p>\n<p>At dchost.com we apply these OPcache patterns across our shared hosting, NVMe VPS, dedicated server and colocation setups, adapting values to each project\u2019s size and traffic profile. If you are unsure where your current bottleneck is \u2013 OPcache, PHP\u2011FPM, MySQL, or storage \u2013 you can always start by measuring, then adjust one layer at a time. Use the baselines in this guide, watch OPcache stats under real traffic, and refine. And if you prefer to focus on your code while we handle the low\u2011level tuning, our team is ready to help you design a hosting architecture where OPcache, PHP\u2011FPM and your applications work together smoothly.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>PHP OPcache is one of the easiest performance wins you can get for WordPress, Laravel and WooCommerce, yet on many servers it is either misconfigured or barely used. When we tune new environments at dchost.com, OPcache is always in the first batch of settings we review \u2013 right after PHP-FPM and basic PHP limits. A [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":3723,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-3722","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3722","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=3722"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3722\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/3723"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=3722"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=3722"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=3722"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}