PHP OPcache Ayarları: WordPress, Laravel ve WooCommerce İçin En İyi Konfigürasyon Rehberi

PHP OPcache Ayarları Neden Bu Kadar Önemli?

WordPress, Laravel veya WooCommerce çalıştırıyorsanız, PHP tarafındaki en büyük performans kazançlarından biri doğrudan PHP OPcache ayarlarından geliyor. DCHost tarafında onlarca projede şunu sıkça görüyoruz: Eklentiler, tema optimizasyonları, veritabanı index’leri yapılmış, ama OPcache hâlâ varsayılan ve eksik ayarlarla çalışıyor. Sonuç; yüksek CPU kullanımı, dalgalı TTFB, trafik artınca bir anda yorulan PHP-FPM süreçleri.

OPcache aslında çok basit bir işi çok iyi yapıyor: PHP dosyalarınızı her istekte yeniden derlemek yerine, derlenmiş halini bellekte tutuyor ve sonraki isteklerde doğrudan bu önbellekten servis ediyor. Bu da hem cevap sürelerini kısaltıyor hem de CPU yükünü ciddi şekilde düşürüyor. Özellikle WooCommerce gibi ağır sorgular çalışan e-ticaret sitelerinde, doğru yapılandırılmış bir OPcache; PHP-FPM ayarları, veritabanı optimizasyonu ve önbellekleme stratejileriyle birleşince fark edilir ölçüde daha stabil bir sistem sağlıyor.

Bu rehberde, DCHost ekibinin sahada sıkça kullandığı OPcache ayarlarını; WordPress, WooCommerce ve Laravel projeleri için ayrı ayrı, senaryo bazlı ve somut örneklerle anlatacağız. Ayrıca OPcache’i PHP-FPM havuz ayarları, deploy süreçleri, Redis/Object Cache ve sunucu tarafı optimizasyonlarla birlikte nasıl düşünmeniz gerektiğini de adım adım ele alacağız.

PHP OPcache Nedir, Diğer Önbelleklerden Farkı Ne?

Önce kavramları netleştirelim. OPcache, PHP’nin içinde gelen bir opcode cache eklentisidir. Yani:

• PHP dosyalarınızı (.php) okur,
• Derler, bytecode (opcode) haline getirir,
• Bu derlenmiş kodu RAM’de saklar ve sonraki isteklerde yeniden derlemeden çalıştırır.

Bu mekanizma; Redis, Memcached veya tam sayfa önbellek (Nginx FastCGI cache, LiteSpeed Cache, Varnish vb.) gibi veri önbelleklerinden farklıdır. Onlar; HTML çıktısını, sorgu sonuçlarını veya key–value verilerini saklarken; OPcache doğrudan PHP kodunun derlenmiş halini saklar. Bu yüzden:

• Her istekte diskten PHP dosyası okumayı azaltır,
• Her istekte derleme maliyetini ortadan kaldırır,
• CPU kullanımını düşürür, özellikle yoğun trafik altında çok fark edilir.

Özellikle WordPress/WooCommerce için OPcache, sunucu tarafı optimizasyon rehberimizin en kritik parçalarından biri. Laravel tarafında ise OPcache, prod ortam optimizasyonu ile birlikte düşünülmesi gereken temel bileşen.

OPcache’i Etkinleştirme ve Temel Ayarlar

Çoğu modern PHP kurulumunda OPcache modülü yüklü gelir, ancak ayarları genellikle varsayılan bırakılır. Özellikle VPS ve dedicated sunucularda, aşağıdaki gibi ayrı bir opcache.ini dosyasıyla çalışmak iyi bir pratiktir:

; /etc/php/8.1/mods-available/opcache.ini veya benzeri bir yol
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=2
opcache.revalidate_path=1
opcache.save_comments=1
opcache.fast_shutdown=1
opcache.max_wasted_percentage=5

Şimdi en kritik direktifleri tek tek sade dille açıklayalım.

opcache.enable ve opcache.enable_cli

• opcache.enable=1: FPM/Apache mod_php gibi web istekleri için OPcache’i açar.
• opcache.enable_cli: CLI (komut satırı) PHP için OPcache. Varsayılan olarak 0 bırakılır, ancak Laravel artisan gibi sık çalışan CLI komutlarında 1 yapmak avantaj sağlayabilir.

Laravel projelerinde, sürekli çalışan queue worker’larınız varsa ve artisan komutlarını yoğun kullanıyorsanız, opcache.enable_cli=1 tercih edilebilir. Bu noktada Laravel queue ve arka plan işler rehberimizle birlikte düşünmek iyi olur.

opcache.memory_consumption

OPcache’in derlenmiş kodlar için kullanacağı RAM miktarı (MB cinsinden). Çok düşük bırakıldığında:

• Yeni script’ler için yer kalmaz,
• Eski dosyalar sürekli atılıp yeniden derlenir,
• Hit rate düşer, CPU yükü artar.

Tipik öneriler:

• Küçük WordPress siteleri: 128 MB
• Orta ölçekli WordPress/WooCommerce veya tek Laravel proje: 256 MB
• Bir sunucuda çoklu site/çoklu Laravel (ajans, SaaS vb.): 256–512 MB

Gerçek ihtiyacı anlamak için ileride anlatacağımız opcache_get_status() ile kullanılan bellek ve parçalanma oranını takip etmek önemli.

opcache.interned_strings_buffer

PHP, aynı metinleri (string) tekrar tekrar kullanırken belleği verimli kullanmak için “interned string” mekanizmasını kullanır. OPcache bunu bellekte saklayabilir.

• Küçük projeler için: 8–16 MB
• Büyük Laravel veya çok eklentili WordPress/WooCommerce için: 16–32 MB

Değer çok düşük kalırsa bazı string’ler intern edilemez ve hafif bir performans kaybı yaşanabilir; çok yüksek olması ise RAM israfına yol açar.

opcache.max_accelerated_files

OPcache’in aynı anda bellekte tutabileceği maksimum PHP dosyası sayısıdır. WordPress çekirdeği, tema ve eklentilerle birlikte kolayca birkaç bin PHP dosyasına ulaşır; Laravel projelerinde de bu sayı yüksektir.

• Küçük WordPress sitesi: 10000
• WooCommerce veya büyük eklenti seti: 20000–40000
• Çoklu site/çoklu proje: 40000–60000 (belleğe göre ayarlanmalı)

Bu değeri çok düşük tuttuğunuzda bazı dosyalar OPcache dışında kalır; hit rate düşer ve derleme maliyeti artar.

opcache.validate_timestamps ve opcache.revalidate_freq

Bu ikili, kod değişikliklerini OPcache’in ne zaman fark edeceğini belirler.

• opcache.validate_timestamps=1: Her revalidate_freq saniyede bir, dosyaların değiştirilme zamanına bakar.
• opcache.revalidate_freq=2: Varsayılan 2 saniyedir; yani en fazla 2 saniye kadar eski kod çalışabilir.

Geliştirme ortamında bu ayar yüksek tutulmaz; hatta 0 bile yapılmaz. Üretim ortamında ise iki temel strateji vardır, bunu aşağıda detaylı ele alacağız:

• WordPress/paylaşımlı hosting: validate_timestamps=1, revalidate_freq=2–5
• CI/CD’li Laravel prod: validate_timestamps=0 ve deploy sırasında PHP-FPM reload

Diğer Önemli Ayarlar

• opcache.save_comments=1: Laravel ve birçok modern framework, type hint ve annotation gibi yorumları kullanır. Bunu kapatmayın.
• opcache.fast_shutdown=1: PHP 8’de etkisi azaldı ama açık bırakmakta sakınca yok.
• opcache.max_wasted_percentage=5: Bellek parçalanması %5’i aşarsa OPcache’i resetler. Çok düşük ayarlarsanız gereksiz reset’ler görebilirsiniz.

PHP 8.x geçişinde OPcache’in de davranışları değiştiği için, versiyon yükseltmelerinde mutlaka PHP 8.x yükseltme kontrol listesi rehberimize göz atmanızı öneririz.

WordPress ve WooCommerce İçin Pratik OPcache Ayarları

WordPress dünyasında her sitenin eklenti ve tema kombinasyonu farklı. Bu yüzden tek bir sihirli OPcache dosyası yok; ama sahada sıkça kullandığımız üç senaryoyu paylaşabiliriz.

1) Küçük Blog veya Kurumsal Site (Düşük–Orta Trafik)

Örnek profil:

• Aylık 10–50K ziyaretçi
• 5–20 eklenti
• Standart blog veya kurumsal içerik

Bu durumda genellikle şu ayarlar yeterli oluyor:

opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.validate_timestamps=1
opcache.revalidate_freq=2
opcache.revalidate_path=1
opcache.save_comments=1

Bu yapıda, kodu güncellediğinizde veya eklenti güncellediğinizde en fazla 1–2 saniye sonra yeni kod devreye girecektir. Paylaşımlı hosting kullanıyorsanız, OPcache ayarlarının bir kısmını hosting panelinizdeki PHP ayarları üzerinden değiştirebilirsiniz; detay için PHP ayarlarını doğru yapmak rehberine de göz atabilirsiniz.

2) WooCommerce Mağazası (Orta Trafik, Çok Eklenti)

WooCommerce; ek sorgular, eklentiler, ödeme modülleri, raporlar vb. yüzünden kod tabanını hızla büyüten bir yapı. Burada OPcache’i biraz daha geniş konfigüre etmek iyi sonuç veriyor:

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=40000
opcache.validate_timestamps=1
opcache.revalidate_freq=2
opcache.revalidate_path=1
opcache.save_comments=1

Bu senaryoda:

• Birden fazla WooCommerce eklentisi (kargo, ödeme, kampanya vb.)
• Gelişmiş tema framework’leri
• SEO, cache, güvenlik eklentileri

derken PHP dosya sayısı kolayca 15–20 binleri buluyor. Bu nedenle max_accelerated_files değerini rahat tutmak kritik.

WooCommerce performansını bütünüyle ele almak isterseniz, veritabanı tarafı için WooCommerce ve büyük katalog siteleri için MySQL indeksleme rehberimizi, PHP-FPM ölçeklemesi için de WordPress ve WooCommerce için PHP-FPM ayarları yazımızı mutlaka birlikte okumanızı tavsiye ederim.

3) Yüksek Trafikli Haber, Blog veya Mağaza

Artık dakikada yüzlerce istek alan, Cache/Redis/CDN kullanılan büyük WordPress veya WooCommerce kurulumlarında yaklaşım biraz değişiyor:

• OPcache bellek: 256–512 MB
• Max accelerated files: 60000+
• validate_timestamps: 0 veya 1 (deploy stratejisine göre)

Büyük yapılarda genelde Nginx FastCGI cache veya LiteSpeed Cache gibi tam sayfa önbellek çözümleri ile OPcache birlikte kullanılıyor. Bu tür mimariler için tam sayfa önbellekleme rehberimiz ve Brotli/Gzip sıkıştırma ayarları yazımız ile birlikte, OPcache’i bir “temel katman” olarak düşünmek en doğrusu.

Laravel Projeleri İçin OPcache ve Deploy Stratejisi

Laravel dünyasında işler biraz daha kontrollü. Çoğunlukla:

• Versiyon kontrol (Git) kullanılıyor,
• Staging–prod ayrımı net,
• Deploy için CI/CD veya en azından bir deploy script’i var.

Bu da bize OPcache tarafında daha agresif ayarlar yapma imkânı veriyor.

Laravel İçin Önerilen Temel OPcache Ayarları

Tipik bir orta–büyük Laravel uygulaması için başlangıç noktası olarak şunları kullanabilirsiniz:

opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=40000
opcache.validate_timestamps=0
opcache.revalidate_freq=0
opcache.save_comments=1

Burada kritik satırlar:

• opcache.enable_cli=1: php artisan komutları için de OPcache avantajı.
• opcache.validate_timestamps=0: Dosya zaman damgalarını hiç kontrol etme; yeni kodu yalnızca biz söyleyince yükle.

Bu modelde deploy süreci önem kazanıyor. Örneğin:

1. Yeni kodu sunucuya çek (git pull veya CI/CD pipeline),
2. Composer install/update (gerekliyse),
3. php artisan config:cache, route:cache, view:cache,
4. En son PHP-FPM’i reload et (veya Apache’yi graceful reload).

FPM reload olduğunda, OPcache de temizlenir ve yeni kod devreye girer. Bu yapıyı; GitHub Actions ile otomatik deploy rehberimiz ve sıfır kesinti CI/CD yazımızla birlikte düşünmek, uzun vadede çok konfor sağlıyor.

Laravel’de Queue Worker ve Horizon ile OPcache

Laravel queue worker’larınız veya Horizon süreçleriniz uzun süre ayakta kaldığı için, kod değişikliği sonrası bu proseslerin de yeniden başlatılması gerekiyor. Aksi halde:

• Web isteklerinde yeni kod,
• Queue worker’da eski kod

gibi karışık bir duruma düşebilirsiniz. Bizim sahada sık kullandığımız pattern:

• Deploy sonunda: sudo systemctl reload php-fpm
• Ardından: Supervisor veya systemd üzerinden worker’ları yeniden başlatmak

Bu mimariyi kurarken, PHP session ve queue işçileri için ayrı PHP-FPM havuzu kurma rehberimiz hem performans hem de izolasyon açısından çok işe yarıyor.

Laravel’de OPcache Preload Kullanımı

PHP 7.4+ ile gelen preload özelliği, sık kullanılan sınıfları PHP başlangıcında belleğe yüklemeye yarar. Laravel tarafında teorik olarak faydalı olsa da, pratikte:

• Framework sürüm yükseltmelerinde preload listelerini güncelleme yükü,
• Geniş kod tabanlarında listeyi doğru çıkarmanın zorluğu

yüzünden birçok projede opsiyonel kalıyor. Yine de yüksek trafik alan, uzun soluklu Laravel projelerinde PHP 8.x + OPcache preload rehberimizdeki örnek yaklaşımları değerlendirebilirsiniz.

validate_timestamps Stratejileri: WordPress ve Laravel’i Farklı Ele Almak

OPcache tarafında en çok kafa karıştıran ayar; opcache.validate_timestamps.

WordPress / WooCommerce için Güvenli Yol

WordPress projelerinde; çoğu zaman FTP veya panel üzerinden dosya değişiklikleri, eklenti–tema güncellemeleri, hatta bazen canlıda ufak düzenlemeler yapıldığını biliyoruz. Bu sebeple:

• opcache.validate_timestamps=1
• opcache.revalidate_freq=2 (veya 3–5)

gibi bir ayar, en güvenli ve pratik yaklaşım. Böylece:

• OPcache her birkaç saniyede bir dosya tarihlerini kontrol ediyor,
• Güncellenen dosyalar yeniden derleniyor,
• Manuel OPcache temizleme ihtiyacı büyük ölçüde ortadan kalkıyor.

Performans maliyeti, kazandırdığı kullanım konforuna göre genellikle kabul edilebilir düzeyde kalıyor.

Laravel ve Kontrollü Deploy İçin Agresif Yol

Laravel gibi sürüm kontrollü projelerde ise tam tersine gitmek çoğu zaman daha mantıklı:

• opcache.validate_timestamps=0
• opcache.revalidate_freq=0

Bu durumda OPcache, dosya sistemine hiçbir ek kontrol yapmıyor. Tüm kod değişimleri, yalnızca bizim başlattığımız PHP-FPM reload veya Apache graceful restart ile devreye giriyor. Özellikle yüksek trafikli uygulamalarda bu, her istek başına yapılan ufak timestamp kontrollerini de ortadan kaldırarak daha stabil bir performans sağlayabiliyor.

OPcache Durumunu İzlemek, Sorunları Teşhis Etmek

Ayarlardan sonra en kritik adım, OPcache’in gerçekten sağlıklı çalışıp çalışmadığını gözlemlemek. Bunun için birkaç pratik yöntem kullanalım.

phpinfo() ve opcache_get_status()

Önce OPcache’in gerçekten aktif olduğunu doğrulayın:

1. Geçici bir info.php dosyası oluşturun:

<?php phpinfo();

2. Tarayıcıdan açın ve “Zend OPcache” bölümünü kontrol edin.

Daha detaylı bilgi için CLI’dan şu komutu çalıştırabilirsiniz:

php -r 'print_r(opcache_get_status());'

Burada özellikle şu metriklere bakın:

• memory_usage: Toplam, kullanılan ve boş OPcache RAM’i
• opcache_statistics: hits, misses, opcache_hit_rate
• interned_strings_usage: interned string belleği doluluk oranı

Hit rate’in %95+ olması idealdir. Sürekli %80–85’lerde gezen bir hit rate, ya belleğin yetmediğini ya da çok fazla farklı PHP dosyasının kullanıldığını gösterebilir.

Bellek Parçalanması ve max_wasted_percentage

Uzun süre çalışan sistemlerde OPcache belleği parçalanır. opcache_get_status() içindeki memory_usage.wasted_percentage değeri %5–10 üzerindeyse:

• opcache.max_wasted_percentage değerinizi kontrol edin,
• Gerekirse OPcache’i müsait bir anda manuel reset edin,
• Uygulamaya sık sık yeni dosya ekleniyorsa, bellek boyutunu artırmayı düşünün.

Yüksek trafikli WordPress/Laravel kurulumlarında bu metrikleri Prometheus, Netdata vb. ile izlemek, VPS kaynak kullanımı izleme rehberimizde anlattığımız gibi alarm üretmek oldukça faydalıdır.

OPcache Temizleme (Reset) Ne Zaman Gerekir?

İdeal dünyada production ortamında manuel OPcache temizliğine pek ihtiyaç duymak istemeyiz. Ama pratikte:

• Yanlış bir deploy,
• Beklenmeyen bir hata veya
• OPcache belleğinin dolup resetlenememesi

gibi durumlarda aşağıdaki komutlarla OPcache’i temizleyebilirsiniz:

<?php
opcache_reset();

veya CLI’dan:

php -r 'opcache_reset();'

Yine de uzun vadeli çözüm; doğru bellek boyutları, doğru max_accelerated_files ve iyi planlanmış bir deploy akışıdır.

OPcache Ayarlarını DCHost Altyapısı ve Diğer Optimizasyonlarla Birlikte Düşünmek

OPcache tek başına mucize yaratmaz; ama doğru altyapı ve ayarlarla birleştiğinde müthiş bir çarpan etkisi oluşturur. Özellikle:

• NVMe diskli VPS veya dedicated sunucular,
• Doğru boyutlandırılmış CPU/RAM,
• İyi ayarlanmış PHP-FPM havuzları,
• Redis/Memcached object cache,
• Nginx/Apache üzerinde doğru cache-control ve sıkıştırma ayarları

ile OPcache’i birlikte düşündüğünüzde hem TTFB hem de genel yanıt sürelerinde ciddi kazanımlar elde edersiniz. Bu resmin bütünü için WordPress için sunucu tarafı optimizasyon ve Laravel prod ortam optimizasyonu yazılarımızı mutlaka birlikte okumanızı öneririz.

DCHost olarak, hem paylaşımlı hosting hem de NVMe tabanlı VPS ve dedicated sunucu altyapılarımızda PHP OPcache’i varsayılan olarak aktif ve optimize şekilde sunuyor, yüksek trafikli WordPress, WooCommerce ve Laravel projelerinde müşterilerimizle birlikte projeye özel ince ayarları yapıyoruz. Eğer kendi projeniz için “benim senaryoma uygun OPcache ayarları tam olarak ne olmalı?” sorusunun net bir cevabını arıyorsanız, altyapınızı ve trafik profilinizi birlikte analiz ederek özel bir öneri seti çıkarmak bizim için günlük işlerden biri.

Özet ve Sonraki Adım: OPcache’i Sadece Açmak Değil, Doğru Ayarlamak

PHP OPcache, WordPress, WooCommerce ve Laravel projelerinde çoğu zaman en hızlı ve en az riskli performans kazancı sağlayan bileşenlerden biri. Ama yalnızca opcache.enable=1 yapmak yetmiyor; bellek boyutunu, dosya sayısı limitlerini, timestamp stratejisini ve CLI davranışını proje türüne göre ayarlamadığınızda potansiyelin önemli bir kısmı boşa gidiyor.

Bu rehberde:

• OPcache’in nasıl çalıştığını ve diğer önbellek türlerinden farkını,
• Temel ayarların ne anlama geldiğini,
• WordPress, WooCommerce ve Laravel için pratik senaryo bazlı konfigürasyonları,
• validate_timestamps için güvenli ve agresif stratejileri,
• OPcache sağlığını nasıl izleyeceğinizi ve sorunları nasıl teşhis edeceğinizi

adım adım ele aldık. Şimdi sırada, kendi sunucunuzda bu ayarları kontrollü şekilde devreye almak ve etkisini ölçmek var. Bunu yaparken, mevcut PHP/FPM ayarlarınızı da gözden geçirmek için PHP limitlerini doğru ayarlama rehberimize göz atmanız iyi bir tamamlayıcı adım olacaktır.

Eğer DCHost üzerinde bir hosting, VPS, dedicated sunucu veya colocation altyapısı kullanıyorsanız ve “trafik artıyor, PHP tarafını olabildiğince verimli hale getirelim” diyorsanız, OPcache ayarlarınızı birlikte gözden geçirip, proje bazlı en iyi konfigürasyonu çıkarmaktan memnuniyet duyarız. İş yükünüz WordPress, WooCommerce, Laravel ya da özel bir PHP uygulaması olsun; doğru OPcache ayarlarıyla hem daha düşük kaynak tüketimi hem de daha akıcı bir kullanıcı deneyimi elde etmek mümkün.