PHP OPcache nedir? PHP OPcache (Zend OPcache), PHP betiklerinin her istekte yeniden derlenmesini (compile) önleyerek, önceden derlenmiş opcode’ları paylaşımlı bellekte (shared memory) tutan yerleşik bir PHP uzantısıdır. WordPress gibi her sayfa isteğinde onlarca PHP dosyasının çalıştığı sistemlerde OPcache, sunucu tarafındaki en temel ve genellikle en çok göz ardı edilen performans katmanlarından biridir. Bu rehberde PHP OPcache’in tam olarak ne yaptığını, WordPress için doğru yapılandırmanın nasıl yapılacağını, hangi ayarların paylaşımlı hosting ile VPS arasında farklılaştığını ve deploy sonrası en sık karşılaşılan “eski dosya çalışıyor” sorununu nasıl çözeceğinizi adım adım ele alıyoruz.
Pratikte sıkça karşılaşılan bir senaryo şöyle işler: bir WordPress sitesi hosting sağlayıcısını değiştirir veya trafiği artar, sayfa yükleme süreleri kötüleşir ve ilk refleks genellikle “sayfa önbelleği eklentisi” kurmak veya CDN eklemek olur. Bu adımlar HTML çıktısını hızlandırsa da, sepet, giriş sayfası veya admin paneli gibi önbelleklenemeyen dinamik isteklerde hiçbir fayda sağlamaz; çünkü bu sayfalar her seferinde PHP’yi baştan çalıştırır. İşte tam bu noktada OPcache’in doğru yapılandırılmış olması, sayfa önbelleğinin dokunamadığı dinamik isteklerde de belirgin bir fark yaratır.
PHP OPcache Nasıl Çalışır?
OPcache Olmadan Bir PHP İsteğinin Yaşam Döngüsü
OPcache devre dışıyken her HTTP isteğinde şu adımlar tekrar tekrar çalışır: PHP dosyası diskten okunur, sözdizimi çözümlenir (parse), ardından çalıştırılabilir opcode’lara derlenir ve son olarak bu opcode’lar Zend Engine tarafından yürütülür. WordPress çekirdeği, aktif tema ve eklentiler dahil olmak üzere tek bir sayfa isteğinde genellikle yüzlerce PHP dosyası bu döngüden geçer. Trafik arttıkça bu tekrarlanan derleme işlemi, sunucu CPU’sunun önemli bir kısmını tüketir.
OPcache Devredeyken Ne Değişir?
OPcache etkinleştirildiğinde, bir dosya ilk kez çalıştırıldığında üretilen opcode’lar paylaşımlı bellekte saklanır. Aynı dosyaya gelen sonraki istekler, parse ve derleme adımlarını tamamen atlayıp doğrudan bellekteki hazır opcode’u çalıştırır. Bu, özellikle çok sayıda küçük dosyadan oluşan WordPress eklenti mimarisinde belirgin bir yanıt süresi iyileşmesi sağlar; CPU, her istekte aynı işi tekrar yapmak yerine yalnızca gerçek iş mantığını çalıştırmaya odaklanır.
OPcache Sunucunuzda Etkin mi? Nasıl Kontrol Edilir?
Birçok paylaşımlı hosting sağlayıcısı OPcache’i varsayılan olarak etkinleştirir, ancak bellek boyutu ve doğrulama ayarları genellikle genel amaçlı, WordPress’e özel optimize edilmemiş değerlerde kalır. Durumu kontrol etmenin en pratik yolu küçük bir PHP betiği çalıştırmaktır:
<?php
// opcache-durum.php - kontrolden sonra dosyayı silmeyi unutmayın
if (function_exists('opcache_get_status')) {
$durum = opcache_get_status(false);
if (!is_array($durum)) { echo "OPcache durumu kullanilamiyor.\n"; exit; }
echo $durum['opcache_enabled'] ? "OPcache ACIK\n" : "OPcache KAPALI\n";
echo "Bellek kullanımı: " . round($durum['memory_usage']['used_memory'] / 1048576, 1) . " MB\n";
echo "Önbelleklenen dosya sayısı: " . $durum['opcache_statistics']['num_cached_scripts'] . "\n";
echo "Isabet oranı (hit rate): " . round($durum['opcache_statistics']['opcache_hit_rate'], 1) . "%\n";
} else {
echo "OPcache uzantısı yüklü değil.\n";
}
Durum betiğini yalnızca kimlik doğrulamalı veya IP kısıtlı bakım alanında çalıştırın, ardından kaldırın. CLI ve PHP-FPM farklı yapılandırma/önbellek kullanabilir; wp cli info web tarafındaki OPcache durumunu kanıtlamaz. Fonksiyon false dönebilir veya restrict_api nedeniyle engellenebilir; örnek bunu kontrol eder.
WordPress İçin Doğru OPcache Ayarları
OPcache’in etkin olması tek başına yeterli değildir; bellek boyutu yetersiz kalırsa yeni dosyaların önbelleğe alınması aksayabilir ve beklenen performans kazancı gerçekleşmez. Aşağıdaki php.ini ayarları, orta ölçekli bir WordPress kurulumu için genel bir başlangıç noktasıdır:
; php.ini veya opcache özel yapılandırma dosyası
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.revalidate_freq=0
opcache.validate_timestamps=1
opcache.save_comments=1
; fast_shutdown PHP 7.2’den beri kaldırıldı; eklemeyin.
max_accelerated_files değeri, aktif eklenti sayısı fazla olan kurulumlarda (özellikle WooCommerce gibi çok dosyalı eklentiler varsa) önemlidir; bu değer dosya sayısının altında kalırsa yeni dosyalar önbelleğe alınamayabilir; restart ve cache_full verileri incelenmelidir. opcache_get_status() çıktısındaki num_cached_scripts değerini, sitenizdeki toplam PHP dosya sayısıyla karşılaştırarak bu değeri gerektiği kadar yükseltebilirsiniz.
| Ayar | Paylaşımlı Hosting (Tipik) | VPS/Dedicated (Önerilen) |
|---|---|---|
| memory_consumption | 64-128 MB (genelde değiştirilemez) | 128-512 MB |
| max_accelerated_files | 2000-4000 (sağlayıcı sınırlı) | 10000-20000+ |
| validate_timestamps | 1 (açık, kontrol dışı erişim sınırlı) | Geliştirmede 1, üretimde deploy sürecine göre 0 |
| Yapılandırma erişimi | Genellikle panel üzerinden sınırlı seçenek | php.ini veya pool tanımına doğrudan erişim |
Bellek Boyutunu Nasıl Doğru Hesaplarsınız?
Bellek ve dosya sınırını memory_usage, cache_full ve restart sayaçlarıyla birlikte değerlendirin. OPcache Redis gibi en az kullanılan dosyayı LRU ile tahliye eden bir önbellek değildir. Dolu bellek veya anahtar tablosu yeni dosyaların önbelleğe alınmasını engelleyebilir ve yeniden başlatma sürecini etkileyebilir; tek bir yüzde eşiğinden teşhis koymayın.
Neden Bu Kadar Çok WordPress Sitesi OPcache’i Yanlış Yapılandırıyor?
Pratikte gözlemlenen yaygın bir örüntü şu: birçok WordPress kurulumu OPcache’i “etkin” olarak bırakır ama hiçbir zaman gerçek dosya sayısına veya bellek ihtiyacına göre ayarlamaz. Bunun başlıca nedeni, OPcache’in varsayılan ayarlarla bile sistemi “çalışır” hale getirmesi; performans kaybı sessiz ve kademeli olduğu için fark edilmesi zor. Bir site trafiği arttıkça veya eklenti sayısı çoğaldıkça isabet oranı düşer, ancak bu düşüş genellikle “site yavaşladı, hosting yetersiz kaldı” şeklinde yanlış teşhis edilir ve doğrudan daha pahalı bir hosting paketine geçiş önerilir. Oysa çoğu durumda sorun, mevcut kaynakların OPcache tarafında verimsiz kullanılmasıdır. Bu yüzden hosting yükseltmeden önce opcache_get_status() çıktısını kontrol etmek, gereksiz maliyeti önleyebilecek ucuz ve hızlı bir ilk adımdır.
WP-CLI ve Sunucu Loglarıyla OPcache İzleme
WP-CLI ile Hızlı Kontrol
VPS veya özel sunucu üzerinde WP-CLI kullanılabiliyorsa, PHP yapılandırma özetine wp cli info komutuyla hızlıca göz atılabilir. Daha ayrıntılı OPcache istatistikleri için doğrudan PHP-FPM durum sayfasını (varsa) veya yukarıdaki durum betiğini kullanmak gerekir.
Sunucu Loglarında Nelere Dikkat Edilmeli?
Out of memory kaydı PHP memory_limit, işletim sistemi veya konteyner limitinden de kaynaklanabilir. Önce hangi süreç ve sınırın dolduğunu belirleyin; her bellek hatasında OPcache belleğini artırmak doğru değildir.
Konteyner (Docker) Ortamlarında OPcache’e Dikkat
Docker gibi konteyner tabanlı dağıtımlarda her deploy genellikle yeni bir konteyner örneği başlatır; bu da OPcache belleğinin sıfırdan doldurulması anlamına gelir. Bu senaryoda validate_timestamps ayarının 0 olması güvenlidir, çünkü zaten her deploy yeni bir bellek alanıyla başlar ve eski koda referans kalmaz. Ancak konteynerler arasında yük dengeleme (load balancing) yapılan çoklu-örnek (multi-instance) kurulumlarda, bir örnekte OPcache ısınırken diğerinde soğuk başlangıç yaşanabilir; bu durumda deploy sonrası ilk birkaç dakikada yanıt sürelerinde geçici bir dalgalanma normal karşılanmalı ve izleme sistemlerinde yanlış alarma yol açmamalıdır.
Nasıl Yapılandırılır: Adım Adım
- Hosting panelinizde veya sunucunuzda PHP sürümünüzle birlikte gelen OPcache uzantısının yüklü olduğunu
php -m | grep -i opcachekomutuyla (VPS) veya panel PHP bilgisi ekranından doğrulayın. - Yukarıdaki
opcache-durum.phpbetiğiyle mevcut bellek kullanımını ve isabet oranını ölçün; ısınma süresini, cache_full ve restart sayaçlarını birlikte değerlendirin; yüzde 99 tek başına yetersiz bellek kanıtı değildir. - Paylaşımlı hostingde php.ini değişikliği genellikle panel üzerinden yapılır; VPS’te değişiklikleri sunucudaki opcache.ini veya php.ini dosyasına yazıp PHP-FPM servisini yeniden başlatın.
- Değişiklik sonrası aynı durum betiğini tekrar çalıştırarak bellek kullanımının ve isabet oranının iyileştiğini doğrulayın.
- Sitenizi Core Web Vitals açısından da kontrol edin; sunucu tarafı yanıt süresindeki (TTFB) iyileşme genellikle LCP metriğine olumlu yansır.
En Büyük Tuzak: Deploy Sonrası Eski Kod Çalışması
opcache.validate_timestamps=0 ayarı, OPcache’in her istekte dosyanın değişip değişmediğini diskten kontrol etmesini tamamen kapatır; bu, üretimde ekstra bir hız kazancı sağlar ama beraberinde ciddi bir tuzak getirir: bir eklenti veya tema dosyasını güncellediğinizde, sunucu OPcache’i el ile temizlemediğiniz sürece eski derlenmiş opcode’u çalıştırmaya devam eder. Bu durum, “dosyayı güncelledim ama site hâlâ eski haliyle çalışıyor” şikayetinin en yaygın nedenlerinden biridir. Çözüm, deploy sürecinize (GitHub Actions, WP-CLI betiği veya panel deploy aracı) otomatik bir opcache_reset() çağrısı ya da PHP-FPM yeniden başlatma adımı eklemektir. Bu konuyu daha önce ele aldığımız WordPress önbellekleme rehberinde anlatılan sayfa önbelleği temizleme mantığıyla birlikte düşünmek, deploy sonrası “değişiklik görünmüyor” sorunlarını büyük ölçüde ortadan kaldırır.
OPcache, Object Cache ve Sayfa Önbelleği Aynı Şey mi?
Bu üç önbellekleme katmanı sık karıştırılır ama tamamen farklı sorunları çözer:
| Katman | Ne Önbelleğe Alır | Etki Alanı |
|---|---|---|
| OPcache | Derlenmiş PHP opcode’ları | Her PHP dosyasının çalıştırılma hızı |
| Object Cache (ör. Redis) | Veritabanı sorgu sonuçları, geçici veriler | Tekrarlanan veritabanı sorgularının önlenmesi |
| Sayfa (Page) Önbelleği | Tam HTML çıktısı | Aynı sayfanın tekrar tekrar üretilmesinin önlenmesi |
Üç katman birbirini dışlamaz; aksine bir arada kullanıldığında en iyi sonucu verir. OPcache PHP çalıştırma hızını, object cache veritabanı yükünü, sayfa önbelleği ise dinamik sayfa üretim maliyetini azaltır. Yalnızca sayfa önbelleği kullanıp OPcache’i göz ardı eden kurulumlarda, önbelleklenmemiş sayfalarda (sepet, hesabım, admin paneli gibi dinamik alanlarda) performans hâlâ zayıf kalabilir.
Sık Yapılan Hatalar ve Çözümleri
Hata 1: OPcache etkin ama bellek yetersiz. Çözüm: opcache_get_status() ile isabet oranını ölçün; cache_full, dolu bellek/anahtar tablosu ve restart sayaçlarına göre kapasiteyi değerlendirin.
Hata 2: Deploy sonrası eski kodun çalışması. Çözüm: Deploy sürecine otomatik opcache_reset() çağrısı veya PHP-FPM yeniden başlatma adımı ekleyin.
Hata 3: CLI ve PHP-FPM önbelleğini aynı sanmak. Kısa CLI süreçlerinde opcache.enable_cli=0 genellikle uygundur; uzun süreli worker farklı değerlendirilebilir. CLI reset’i web sürecinin önbelleğini temizlemez.
Hata 4: Paylaşımlı hostingde php.ini değişikliğinin uygulanmaması. Çözüm: Değişikliği panel üzerinden yapıp PHP sürümünü panelden yeniden seçin/kaydedin; bazı paylaşımlı sistemlerde bu adım önbelleği zorunlu olarak sıfırlar.
Hata 5: Object cache ile OPcache’i karıştırıp yalnızca birini yapılandırmak. Çözüm: İkisini birbirinin yerine değil, birbirini tamamlayan katmanlar olarak birlikte planlayın.
Hata 6: Hosting yükseltmeden önce mevcut OPcache verimliliğini kontrol etmemek. Çözüm: Daha pahalı bir pakete geçmeden önce isabet oranını ve bellek kullanımını ölçün; çoğu yavaşlama sorunu ek kaynak almadan, yalnızca doğru yapılandırmayla çözülebilir.
Hata 7: Test/geliştirme ortamında üretimdekiyle aynı validate_timestamps değerini kullanmamak. Çözüm: Geliştirme ortamında dosya değişikliklerinin anında yansıması için validate_timestamps=1 tutulmalı; yalnızca üretim ortamında ve deploy sürecine sıfırlama adımı eklendikten sonra 0 değeri değerlendirilmelidir.
İleri Seviye Seçenek: OPcache Preloading
PHP 7.4 ve üzeri sürümlerde gelen opcache.preload özelliği, belirlediğiniz bir betikte tanımlı sınıf ve fonksiyonları PHP-FPM veya sunucu süreci başlarken bir kez yükleyip, bu süreç çalıştığı sürece bellekte kalıcı olarak tutar. Normal OPcache davranışında bir dosya yalnızca ilk çağrıldığında önbelleğe alınırken, preloading ile sık kullanılan çekirdek dosyalar sunucu başlar başlamaz hazır hale gelir ve isteğe bağlı revalidasyon kontrolünden bile muaf tutulur.
; php.ini içine eklenir
opcache.preload=/var/www/site/preload.php
opcache.preload_user=www-data
WordPress çekirdeği eklenti mimarisi gereği preloading için doğrudan resmi bir yapılandırma sunmaz ve bu özelliği devreye almak, sunucu sürecinin yeniden başlatılmasını (dolayısıyla kısa bir kesinti penceresini) gerektirir. Bu nedenle preloading, genellikle yüksek trafikli, özel sunucu ortamında çalışan ve deploy sürecini tam kontrol eden ekipler için değerlendirilmesi gereken bir ileri seviye seçenektir; standart paylaşımlı hosting kurulumlarında bu ayara erişim genellikle mümkün olmaz ve yukarıdaki temel bellek/dosya sayısı ayarları çoğu site için yeterli kazanımı sağlar.
OPcache Değişikliğinin Etkisini Nasıl Ölçersiniz?
Bir ayarı değiştirdikten sonra etkisini gözle değil, ölçümle doğrulamak gerekir. Sunucu tarafı yanıt süresini (TTFB – Time to First Byte) ölçmenin en basit yolu, tarayıcının geliştirici araçlarındaki Ağ (Network) sekmesinde ana HTML isteğinin “Waiting” süresine bakmaktır. Daha sistematik bir ölçüm için aynı sayfayı değişiklik öncesi ve sonrası birer dakika arayla, önbelleği devre dışı bırakarak (ör. sorgu parametresi ekleyerek) beşer kez yükleyip ortalama TTFB değerlerini karşılaştırmak, OPcache ayarının gerçek etkisini gürültüden ayıklamaya yardımcı olur. Bu ölçümü, sitenizin genel hız durumunu değerlendirdiğimiz Core Web Vitals rehberimizdeki LCP ölçüm yöntemiyle birlikte kullanmak, sunucu tarafı iyileştirmenin kullanıcı tarafında hissedilen etkisini de gösterir. Değişiklik sonrası TTFB’de gözle görülür bir iyileşme yoksa, darboğazın OPcache değil veritabanı sorguları veya harici API çağrıları olabileceğini düşünüp o katmanları incelemek gerekir.
Kime, Hangi Durumda Uygun?
Orta-yüksek trafikli, çok sayıda eklenti çalıştıran veya WooCommerce gibi dinamik sayfalar üreten WordPress siteleri için OPcache ayarlarını gözden geçirmek, genellikle en düşük efor/en yüksek getiri oranına sahip optimizasyonlardan biridir. Çok düşük trafikli, birkaç sayfalık basit bir kurumsal site için varsayılan hosting ayarları çoğu zaman yeterlidir; ancak sepet, üyelik girişi veya sık güncellenen içerik gibi önbelleklenemeyen dinamik sayfaları olan siteler, OPcache’i doğru boyutlandırmadan yalnızca sayfa önbelleğine güvendiğinde performans sorunlarıyla karşılaşmaya devam eder. Çok sayıda eş zamanlı yazarın içerik ürettiği haber sitelerinde veya sık ürün güncellemesi yapılan WooCommerce mağazalarında, sayfa önbelleği sık sık temizlendiği için asıl performans yükü OPcache ve object cache katmanlarına biner; bu tür sitelerde OPcache yapılandırmasının doğru yapılması, diğer önbellek katmanlarından bile daha kritik hale gelir. Veritabanı tarafındaki ek optimizasyon fırsatları için wp_options optimizasyonu rehberimize de göz atabilirsiniz; OPcache ve veritabanı optimizasyonu birlikte ele alındığında sunucu tarafı performansında daha bütüncül bir iyileşme elde edilir.
Sonuç
PHP OPcache, WordPress performansının genellikle arka planda kalan ama etkisi doğrudan hissedilen bir katmanıdır. Doğru bellek boyutu, yeterli dosya sayısı limiti ve deploy sürecine entegre edilmiş bir sıfırlama adımıyla yapılandırıldığında, sunucu tarafı yanıt süresinde gözle görülür bir iyileşme sağlar. OPcache’i object cache ve sayfa önbelleğiyle birlikte, birbirini tamamlayan üç katman olarak planlamak, performans optimizasyonunda en sağlam yaklaşımdır. Resmi parametre açıklamaları ve varsayılan değerler için PHP’nin resmi OPcache dokümantasyonuna başvurabilirsiniz. Değişiklik yapmadan önce ölçüm, yaptıktan sonra tekrar ölçüm alışkanlığını sürdürmek, hem OPcache hem de diğer performans ayarlarında zaman içinde birikimli ve kalıcı bir iyileşme sağlar.
Sık Sorulan Sorular
1) PHP OPcache nedir, neden önemlidir?
PHP OPcache, PHP betiklerinin derlenmiş halini bellekte tutan bir uzantıdır; her istekte yeniden derleme yapılmasını önleyerek sunucu tarafı yanıt süresini belirgin şekilde azaltır.
2) OPcache’i nasıl etkin olup olmadığını anlarım?opcache_get_status() fonksiyonunu çağıran küçük bir PHP betiğiyle veya hosting panelinizin PHP bilgi ekranından kontrol edebilirsiniz.
3) Deploy sonrası site neden eski haliyle çalışmaya devam ediyor?opcache.validate_timestamps=0 ayarı açıkken OPcache dosya değişikliklerini otomatik algılamaz; deploy sürecine opcache_reset() veya PHP-FPM yeniden başlatma adımı eklemek bu sorunu çözer.
4) OPcache ile Redis object cache aynı şeyi mi yapar?
Hayır. OPcache PHP kodunun çalıştırılmasını hızlandırır, Redis object cache ise veritabanı sorgu sonuçlarını önbelleğe alarak veritabanı yükünü azaltır; ikisi birbirini tamamlar.
5) Paylaşımlı hostingde OPcache ayarlarını değiştirebilir miyim?
Çoğu paylaşımlı hosting sağlayıcısı sınırlı sayıda OPcache ayarını panel üzerinden değiştirmenize izin verir; tam kontrol için genellikle VPS veya özel sunucu gerekir.
6) max_accelerated_files değerini ne kadar yüksek tutmalıyım?
Sitenizdeki toplam PHP dosya sayısının üzerinde bir değer seçilmesi önerilir; opcache_get_status() çıktısındaki önbelleklenen dosya sayısını referans alarak bu değeri kademeli olarak artırabilirsiniz.
7) OPcache preloading her siteye önerilir mi?
Hayır. Preloading, sunucu sürecinin yeniden başlatılmasını gerektiren ve genellikle yalnızca özel sunucu/VPS ortamında tam kontrol sahibi ekiplerin uygulayabileceği ileri seviye bir seçenektir; çoğu WordPress sitesi için temel bellek ve dosya sayısı ayarları yeterli performans kazancı sağlar.
Deploy ve WordPress Güncellemeleri
CLI’de opcache_reset çağırmak PHP-FPM önbelleğini temizlemez; doğru web sürecinde kontrollü reset veya FPM yeniden yükleme gerekir. Reset uç noktasını internete açık bırakmayın. validate_timestamps=0 yalnızca kodun her değişiminde ilgili süreçler yenileniyorsa değerlendirilebilir; konteyner içindeki otomatik eklenti güncellemesi veya bağlı volume değişikliği yine eski kod yaratabilir. Sorgu parametresi sayfa önbelleğini mutlaka atlatmaz; test isteğinin gerçekten cache MISS olduğunu kontrol edin. OPcache çalışma sonucunu, SQL’i veya dış API yanıtını saklamaz.
Teknik kaynak: PHP — OPcache yapılandırma referansı.
