WordPress, Laravel ve WooCommerce için PHP OPcache Ayarları

PHP OPcache Ayarlarını İş Yüküne Göre Planlayın

WordPress, Laravel veya WooCommerce çalıştırıyorsanız, PHP OPcache ayarları PHP tarafındaki performans optimizasyonunun önemli bir parçasıdır. Eklenti, tema ve veritabanı optimizasyonlarının yanında OPcache yapılandırmasını da değerlendirmek gerekir. Varsayılan ayarların yeterliliği uygulamaya bağlıdır; yüksek CPU kullanımı veya dalgalı TTFB tek başına OPcache ayarlarının yetersiz olduğunu göstermez.

OPcache, önbelleğe alınabilen PHP dosyalarının derlenmiş kodunu bellekte tutar; sonraki kullanımlarda yeniden derleme işini azaltır. Bu da cevap sürelerini kısaltabilir ve CPU yükünü azaltabilir; kazancın büyüklüğü iş yüküne bağlıdır. Özellikle WooCommerce gibi e-ticaret sitelerinde OPcache’i; PHP-FPM ayarları, veritabanı optimizasyonu ve diğer önbellekleme stratejileriyle birlikte değerlendirmek gerekir.

Bu rehberde, OPcache ayarlarını; WordPress, WooCommerce ve Laravel projeleri için ayrı ayrı, örnek senaryolar üzerinden 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:

• Önbellek isabetlerinde PHP kaynak dosyasını yeniden okuma ihtiyacını azaltabilir,
• Önbellekteki derlenmiş kod yeniden kullanıldığında derleme işini azaltır,
• CPU kullanımını azaltabilir; etkisi iş yüküne bağlıdır.

Özellikle WordPress/WooCommerce için OPcache, sunucu tarafı optimizasyon rehberimizin bileşenlerinden 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

Bu PHP 8.3+ yapılandırma örneği, OPcache’in ilgili web SAPI’si için kurulu ve yüklenmiş olmasını gerektirir. opcache.enable=1 eklentiyi yüklemez. Yüklü değilse kuruluma uygun zend_extension tanımı gerekir; paket/hosting tarafından sağlanan mevcut yükleyiciyi çoğaltmayın. Dosya yolları ve etkinleştirme yöntemi kuruluma bağlıdır. Bu dosyalar yönetici tarafından ilgili SAPI için uygulanır; tam örneği .user.ini dosyasına kopyalamayın. Özellikle VPS ve dedicated sunucularda, aşağıdaki gibi ayrı bir opcache.ini dosyasıyla çalışmak iyi bir pratiktir:

; PHP 8.3+ için, ilgili SAPI'nin okuduğu opcache.ini dosyasında
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.max_wasted_percentage=5
opcache.file_update_protection=2
opcache.enable_file_override=0
opcache.jit=0
opcache.jit_buffer_size=0

Değişiklikleri uygularken gerçek PHP-FPM servisini/master sürecini belirleyip dağıtım aracınızla kontrollü reload yapın; bu işlem o master’ın tüm worker’larını etkiler. Apache mod_php kullanıyorsanız ilgili web servisinin yapılandırmayı yeniden okuma yöntemini kullanın. Ayrı bir CLI sürecindeki reset, web OPcache’ini temizleme yöntemi değildir. Şimdi temel direktifleri açıklayalım.

Direktiflerin sürüm ve yetki kapsamını resmî PHP OPcache yapılandırma kılavuzuyla karşılaştırın.

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ı 0’dır. Dosya önbelleği yapılandırılmadığında, ayrı ayrı başlatılan CLI komutları arasında bellek önbelleği sıcak kalmaz; sık Artisan çağrısı tek başına opcache.enable_cli=1 için kazanç gerekçesi değildir.

Uzun ömürlü queue worker’larında opcache.enable_cli=1 etkisi, aynı süreçte tekrar derleme ihtiyacına ve iş yüküne bağlıdır; yalnızca uzun süre çalışmaları kazanç garantisi değildir. Etkiyi kendi iş yükünüzde ölçün; deploy sırasında worker’ların kontrollü yeniden başlatılmasını ayrıca planlayın. 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 önbellekte yer kalmayabilir.
• OPcache eski kayıtları LRU/FIFO gibi sürekli tahliye etmez; önbellek kaçırmalarında kod yeniden derlenebilir veya yapılandırılmış dosya önbelleği kullanılabilir.
• Tükenme yollarında koşullara bağlı yeniden başlatma planlanabilir. Kullanılan/boş/boşa çıkan bellek, kaçırmalar ve yeniden başlatma sayaçlarını izleyin.

Başlangıç için örnek bellek değerleri:

• 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 anlatılan opcache_get_status() çıktısındaki kullanılan, boş ve boşa çıkan bellek ile anahtar kapasitesini izleyin. Boşa çıkan bellek yüzdesi, genel bir bellek parçalanması ölçümü değildir.

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.

• Başlangıçta değerlendirilebilecek örnekler: küçük projelerde 8–16 MB; daha geniş kod tabanlarında 16–32 MB.
• Değeri proje adına göre kesinleştirmeyin; interned_strings_usage içindeki kullanılan ve boş baytları izleyin.

Mevcut tamponun yeterli olup olmadığını kullanım verisiyle değerlendirin. Daha büyük bir değer için PHP süreçleri, veritabanı ve diğer servislerle birlikte toplam bellek bütçesinde yer bulunmalıdır; ölçüm olmadan performans kazancı varsaymayın.

opcache.max_accelerated_files

OPcache hash tablosundaki anahtar/script kapasitesini belirler. Etkin kapasite, yapılandırılan değere eşit veya daha büyük ilk desteklenen asal sayıya yuvarlanır; örneğin 20000 için 32531 kullanılır. WordPress çekirdeği, tema/eklentiler ve Laravel vendor/app dizinlerinin ihtiyacı kuruluma göre değişir; script sayısı ile kullanılan anahtar sayısını ayrı izleyin.

Şu değerler yalnız yapılandırma örnekleridir: küçük bir WordPress kurulumu için 10000, geniş WordPress/WooCommerce veya Laravel kod tabanları için 20000 ya da 40000 değerlendirilebilir. Etkin anahtar sınırını ve kalan kapasiteyi durum çıktısından kontrol edin; daha yüksek dosya limiti bellek baytlarını artırmaz.

Anahtar tablosu dolduğunda yeni script’ler paylaşılan bellek önbelleğine alınamayabilir. Bunun kaçırmalara, yeniden derleme işine ve koşullu restart durumuna etkisini ölçün; yapılandırılmış dosya önbelleğini de hesaba katın.

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: Dosya değişikliklerini istek sırasında, opcache.revalidate_freq aralığına göre kontrol eder.
• opcache.revalidate_freq=2: Varsayılan kontrol aralığıdır; arka planda çalışan iki saniyelik bir zamanlayıcı veya kesin yeni koda geçiş süresi değildir. Çalışmakta olan kodu değiştirmez; uzun ömürlü süreçler kendi kontrollü yeniden başlatma protokolünü gerektirir.

Geliştirmede opcache.validate_timestamps=1 ile opcache.revalidate_freq=0, her istekte güncelleme kontrolü sağlar. opcache.validate_timestamps=0 ise periyodik doğrulamayı kapatır ve opcache.revalidate_freq dikkate alınmaz. Ancak opcache.file_update_protection veya opcache.max_file_size sıfır değilse derleme anında zaman damgası kontrolü yine yapılabilir. Üretimde iki temel strateji vardır:

• WordPress/paylaşımlı hosting: opcache.validate_timestamps=1, örnek kontrol aralığı olarak opcache.revalidate_freq için 2–5 saniye
• CI/CD’li Laravel prod: opcache.validate_timestamps=0 ve deploy sırasında doğru web SAPI’sinin önbelleğini kontrollü yenileme; FPM’de gerçek master’a reload, tüm worker’ları kapsar

Diğer Önemli Ayarlar

• opcache.save_comments=1: Doc-comment annotation’larını korur; yorum ayrıştıran bağımlılıklar için uyumlu başlangıç değeridir. Yerel PHP tür bildirimleri ve PHP 8 attribute’ları yorum değildir. Laravel’in tümü için genel bir yorum bağımlılığı varsayılmaz.
• opcache.fast_shutdown: PHP 7.2.0’da kaldırıldı; PHP 8.x yapılandırmasına eklenmez. Uygun hızlı kapanış davranışı PHP tarafından otomatik kullanılır.
• opcache.max_wasted_percentage=5: Boşa çıkan belleğin yüzdesi için eşiktir. Boş bellek yetersizliği gibi tükenme koşullarında yeniden başlatma planlanmasına katkı verir; yalnızca %5’e ulaşılması anında reset veya periyodik bellek birleştirme anlamına gelmez.

opcache.revalidate_path=1, include_path üzerinden aynı adlı dosyaların aranmasıyla ilgilidir; bütün realpath önbelleklerini temizlemez. Örneklerde opcache.file_update_protection=2 korunur. Bunu 0 yapmak için her dosya güncellemesinin tamamlanmış dosyayı atomik olarak yayımladığı doğrulanmalıdır; NVMe disk tek başına yeterli değildir. JIT için de ölçüm yoksa opcache.jit=0 ve opcache.jit_buffer_size=0 ile başlayın. PHP içindeki yoğun hesaplamayı hızlandırma olasılığı, yerel eklentinin içinde yapılan işi otomatik hızlandıracağı anlamına gelmez.

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; aşağıda farklı ihtiyaçları ele alan üç örnek senaryo yer alıyor.

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

Aşağıdaki ziyaretçi ve eklenti sayıları yalnızca örnek profil tarifidir; OPcache bellek veya anahtar kapasitesini tek başına belirlemez:

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

Aşağıdaki ayarlar bu profil için bir başlangıç örneğidir; yeterliliklerini kullanılan bellek ve önbellek istatistikleriyle değerlendirin:

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
opcache.file_update_protection=2
opcache.enable_file_override=0
opcache.jit=0
opcache.jit_buffer_size=0

Bu yapıda kod veya eklenti güncellemeleri, ilgili dosyaya gelen isteklerde kontrol aralığına göre fark edilir; 1–2 saniyede kesin geçiş garanti edilmez ve çalışmakta olan kod değişmez. Paylaşımlı hosting kullanıyorsanız, değiştirebileceğiniz OPcache ayarları sağlayıcının izinlerine ve panelin sunduğu seçeneklere bağlıdır; hosting panelinizdeki PHP ayarlarını bu kapsamda inceleyin. Detay için PHP ayarlarını doğru yapmak rehberine de göz atabilirsiniz.

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

WooCommerce eklentileri, ödeme modülleri ve raporlama bileşenleri PHP kod tabanını büyütebilir. Aşağıdaki değerleri, bellek kullanımına ve önbelleğe alınan dosya sayısına göre değerlendireceğiniz bir başlangıç örneği olarak ele alın:

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
opcache.file_update_protection=2
opcache.enable_file_override=0
opcache.jit=0
opcache.jit_buffer_size=0

Bu senaryoda aşağıdaki bileşenler dosya kapasitesini etkiler. Buradaki tam php.ini örnekleri sunucu yöneticisi içindir; bellek, dosya kapasitesi, enable_cli ve save_comments gibi INI_SYSTEM ayarları .user.ini üzerinden değiştirilemez:

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

birlikte kullanıldığında PHP dosya sayısı kuruluma göre değişir. Bu nedenle max_accelerated_files değerini önbelleğe alınan dosya sayısını ve kalan kapasiteyi izleyerek belirleyin.

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ı birlikte değerlendirebilirsiniz.

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

Büyük WordPress veya WooCommerce kurulumlarında aşağıdaki kapasite değerleri değerlendirilebilir; ancak yalnızca istek sayısına veya Redis/CDN kullanımına bakarak bu değerleri gerekli kabul etmeyin. Bellek ve dosya kapasitesi ihtiyacını OPcache metrikleriyle belirleyin:

• opcache.memory_consumption için 256–512 MB, ölçümle değerlendirilecek örnek bir aralıktır.
• Anahtar ihtiyacı önceki örnekleri aşıyorsa opcache.max_accelerated_files için örneğin 60000 değerlendirilebilir; etkin asal sınıra yuvarlamayı ve bellek bütçesini kontrol edin.
• opcache.validate_timestamps seçimi trafik miktarına değil, bütün kod güncelleme ve geri dönüş yollarının yönetilip doğrulanmasına bağlıdır.

Nginx FastCGI cache veya LiteSpeed Cache gibi tam sayfa önbellek çözümleri ile OPcache farklı katmanlarda birlikte kullanılabilir. Bu tür mimariler için tam sayfa önbellekleme rehberimiz ve Brotli/Gzip sıkıştırma ayarları yazımız ile birlikte, bu katmanların etkisini ayrı ölçün.

Laravel Projeleri İçin OPcache ve Deploy Stratejisi

Kontrollü bir Laravel deploy senaryosunda şu koşulların sağlandığını varsayalım:

• 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 koşullara ek olarak, her deploy’da OPcache yenilemesini ve yeni kodun devreye girdiğini doğrulayan bir süreç gerekir; sürüm kontrolü tek başına yeterli değildir.

Kontrollü Laravel Yayını İçin Koşullu OPcache Örneği

Aşağıdaki örnek, her deploy’da OPcache yenilemesi yapılan ve sonucu doğrulanan orta–büyük bir Laravel uygulaması içindir; genel bir varsayılan olarak uygulanmamalıdır:

Aynı koşul geri dönüşte de geçerlidir. Bu örnekteki CLI etkinleştirmesini yalnız ölçülmüş ihtiyaç varsa kullanın; PHP-FPM ve CLI farklı yapılandırma dosyaları okuyabilir. Sık başlatılan bağımsız Artisan komutları varsayılan olarak ortak sıcak bellek önbelleği paylaşmaz.

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
opcache.file_update_protection=2
opcache.enable_file_override=0
opcache.jit=0
opcache.jit_buffer_size=0

Burada kritik satırlar:

• opcache.enable_cli=1: php artisan komutlarında performans kazancı varsaymak yerine etkisini ölçün.
• opcache.validate_timestamps=0: İsteklerdeki periyodik zaman damgası doğrulamasını kapatır. file_update_protection veya max_file_size sıfır değilse derleme sırasında kontrol yine yapılabilir. Bu durumda opcache.revalidate_freq=0 etkisizdir.

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

1. Tamamlanmış ve test edilmiş sürümü yeni bir release dizininde hazırla; çalışan dosyaların üzerine parça parça yükleme.
2. Test edilmiş, sürüm kontrolüne alınmış composer.lock sürümlerini composer install ile kur. update, yeni sürümleri çözümleyen ve ayrıca test edilmesi gereken bağımlılık değişikliği sürecine aittir.
3. Uygulamanın kullandığı php artisan config:cache, route:cache ve view:cache adımlarını doğru sürüm dizini ve ortam ayarlarıyla hazırla.
4. Sürüm geçişini test edilmiş yöntemle yap; HTTP isteklerini sunan PHP çalışma bağlamında OPcache yenilemesini uygula ve yeni kodu doğrula. FPM için aşağıdaki master yaşam döngüsünü dikkate al; aynı akışı geri dönüşte de doğrula.

PHP-FPM’de belgelenen SIGUSR2 işlemi, ilgili master’ın tüm worker’larını ve FPM yapılandırmasını/binary’sini graceful olarak yeniden yükler; tek havuza özgü değildir. Gerçek servis/master eşlemesini ve servis reload işleminin ne yaptığını doğrulayın. Apache üzerinden FPM kullanılıyorsa yalnızca Apache’yi yenilemek FPM yaşam döngüsünün yerine geçmez; mod_php için de graceful işlemi koşulsuz OPcache temizliği saymayın. Yeni sürümün HTTP üzerinden sunulduğunu doğrulayın. Bu yapıyı; GitHub Actions ile otomatik deploy rehberimiz ve sıfır kesinti CI/CD yazımızla birlikte değerlendirebilirsiniz.

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. Örnek bir deploy akışı:

• Deploy sonunda: HTTP PHP bağlamının OPcache yenilemesini tamamlamak; FPM kullanılıyorsa doğrulanmış servis/master için kontrollü yeniden yükleme uygulamak (servis adı dağıtım ve PHP sürümüne bağlıdır)
• Ardından: Çalışan işlerin yarıda kesilmesini önleyecek şekilde Supervisor veya systemd üzerinden worker’ları yeniden başlatmak

Queue worker’lar uzun ömürlü CLI süreçleridir; FPM havuzları tarafından yönetilmez ve deploy’da ayrı yeniden başlatma süreci gerektirir. PHP session ve queue işçileri için ayrı PHP-FPM havuzu kurma rehberimizi bu ayrımı koruyarak, HTTP isteklerini sunan PHP süreçlerinin havuz düzeni bağlamında değerlendirin.

Laravel’de OPcache Preload Kullanımı

PHP 7.4 ile gelen preload, sunucu başlangıcında seçilen PHP dosyasını derleyip çalıştırır; bu dosya başka dosyaları da yükleyebilir. Burada tanımlanan sınıf ve fonksiyonlar sunucu kapanana kadar kullanılabilir. Bu nedenle preload değişikliğini olağan opcache_reset() ile değiştirilmiş sınıfların anında yüklenmesi gibi düşünmeyin; gerçek PHP çalışma ortamının yeniden başlatma ve yayın yaşam döngüsünü test edin.

• Framework, bağımlılık ve preload listesi değişikliklerini birlikte test edin.
• Başlangıç script’inin yan etkilerini ve dosya erişimlerini inceleyin; uygun sınırlı işletim sistemi kimliğiyle çalıştırın.
• Yararını bellek kullanımı ve gerçek iş yüküyle ölçün; bu rehber hazır bir üretim preload listesi sağlamaz.

Preload zorunlu değildir. Sürüm geçişini planlarken PHP yükseltme kontrol listemizdeki örnek yaklaşımları değerlendirebilirsiniz.

validate_timestamps Stratejileri

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

Panelden Güncellenen WordPress ve WooCommerce

WordPress projelerinde dosyalar panel üzerinden değiştiriliyor veya eklenti–tema güncellemeleri yapılıyorsa:

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

gibi bir ayar, bu güncelleme biçimi için pratik bir seçenek olabilir. Böylece:

• OPcache, istekler sırasında ilgili dosyanın doğrulama aralığı dolmuşsa zaman damgasını kontrol eder; arka planda çalışan bir tarayıcı değildir,
• Güncellenen dosyalar yeniden derleniyor,
• Manuel OPcache temizleme ihtiyacı büyük ölçüde ortadan kalkıyor.

Kontrol aralığını beklenen güncelleme davranışı ve ölçülen ek maliyetle seçin. Değişikliği farklı HTTP isteklerinde doğrulayın; dosya zaman damgası kontrolü, çok dosyalı bir güncellemeyi atomik hâle getirmez.

Tüm Değişiklik Yolları Denetlenen Yayınlar

Laravel gibi sürüm kontrollü projelerde, her deploy’da OPcache yenilemesi yapılıyor ve yeni kodun devreye girdiği doğrulanıyorsa şu alternatif değerlendirilebilir:

Buna panel, eklenti güncellemesi, bakım script’i ve geri dönüş dâhil bütün üretim kodu değişiklikleri dahildir. Bu yolların biri bile yenileme akışının dışında kalıyorsa periyodik doğrulamayı açık tutun.

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

Bu ayar periyodik zaman damgası doğrulamasını kapatır; tüm dosya sistemi kontrollerini kaldırmaz. Derleme zamanı istisnaları yukarıda açıklanmıştır. revalidate_freq burada yok sayılır; yalnızca validate_timestamps=1 iken 0 her istekte kontrol anlamına gelir. Değişiklikleri ilgili HTTP PHP bağlamında OPcache reset/invalidation veya doğrulanmış sunucu yaşam döngüsüyle devreye alın. Reset, çalışmakta olan kodu değiştirmez. Sembolik bağlantıyla sürüm geçişinde realpath önbelleklerini ve uzun ömürlü süreçleri de kapsayan test edilmiş deploy akışı gerekir; yalnızca bağlantıyı değiştirmek yeni kod garantisi değildir.

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.

Doğru PHP Çalışma Ortamında Durum Kontrolü

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

1. Erişimini yalnızca yetkili yöneticilerle sınırlandırdığınız bir konumda 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. Kontrol tamamlanınca dosyayı silin.

Aşağıdaki komut yalnızca CLI önbellek örneğini gösterir, web/FPM önbelleğini değil. CLI’da OPcache eklentisi yüklü, etkin ve opcache.enable_cli=1 olmalıdır. Fonksiyon yoksa eklenti kullanılabilir değildir; false durum bilgisinin alınamadığını gösterir. API yol kısıtlaması da erişimi engelleyebilir.

php -r 'if (!function_exists("opcache_get_status")) { exit("OPcache API yok\n"); } $s = opcache_get_status(false); if ($s === false) { exit("OPcache durumu alınamadı\n"); } print_r($s);'

Web önbelleği için aynı durum çağrısını, hedef HTTP isteklerini sunan PHP SAPI/master bağlamında, yalnızca yetkili yöneticilerin erişebildiği geçici tanılama aracında çalıştırın ve sonra kaldırın. Herkese açık durum veya reset uç noktası oluşturmayın. Doğru örnekten alınan çıktıda şu metriklere bakın:

opcache_get_status() belgesi, dönüş alanlarını ve API erişim kısıtlarını açıklar.

• memory_usage: used_memory, free_memory, wasted_memory bayt cinsindendir; current_wasted_percentage yüzdedir.
• opcache_statistics: hits, misses, opcache_hit_rate; ayrıca num_cached_keys/max_cached_keys kapasitesi ve oom_restarts, hash_restarts, manual_restarts sayaçları
• interned_strings_usage: buffer_size, used_memory, free_memory bayt; number_of_strings adettir. Doluluk yüzdesi, buffer_size sıfırdan büyükse 100 × used_memory / buffer_size ile hesaplanır.

Hit rate için tek bir evrensel “ideal” eşik kullanmayın. Kendi uygulamanızda zaman içindeki değişimi bellek kullanımı ve dosya kapasitesiyle birlikte değerlendirin; düşük bir oran tek başına bellek yetersizliğini kanıtlamaz.

Düşük boş bellek ve bellek tükenmesiyle ilişkili oom_restarts, opcache.memory_consumption değerlendirmesine yön verir. Anahtar doluluğu ve hash_restarts ise opcache.max_accelerated_files için ayrı kanıttır. Sayaçların sıfırlanmasını ve ısınma dönemini dikkate alın; yalnız kısıtlı olan kaynağı, hostta bellek varsa artırın.

Boşa Çıkan Bellek ve Koşullu Yeniden Başlatma

Uzun çalışma süresi tek başına kaçınılmaz parçalanma kanıtı değildir. memory_usage.current_wasted_percentage boşa harcanan belleğin yüzdesidir; genel parçalanma ölçümü değildir. Sabit %5–10 reset eşiği yerine:

• Kullanılan, boş ve boşa harcanan belleği; dosya kapasitesini, misses değerlerini ve yeniden başlatma durum/istatistiklerini iş yüküyle birlikte izleyin.
• opcache.max_wasted_percentage, boş bellek yetersizken yeniden başlatma planlamasına katılan eşiktir; tek başına periyodik bir parçalanma giderici değildir.
• Kapasite artışını veya kontrollü yenilemeyi gözlenen darboğaza göre planlayın; yalnızca çalışma süresine ya da tek yüzdeye göre reset uygulamayın.

Bu metrikleri izleme sisteminize alırken kullanılan exporter veya veri toplayıcının hangi PHP çalışma ortamını sorguladığını doğrulayın. Genel bir host izleme aracı kurmak, FPM OPcache verisinin kendiliğinden toplandığı anlamına gelmez. Alarm eşiklerini iş yükü ve yayın dönemleriyle ilişkilendirin; VPS kaynak kullanımı izleme rehberimiz host metrikleri için tamamlayıcıdır.

OPcache Temizleme (Reset) Ne Zaman Gerekir?

Reset’i bir performans alışkanlığı olarak kullanmayın. Önce doğru PHP örneğini, etkin ayarları, önbellek kapasitesini ve son yayın değişikliklerini belirleyin. Bir yenileme gerekiyorsa bunu yetkili dağıtım veya bakım akışının parçası yapın:

• Kod değişikliği veya geri dönüş için doğru önbellekte planlanan yenileme.
• Teşhis edilmiş bir OPcache durumunu kontrollü olarak yenileme.
• Başlatılmış veya bekleyen restart durumunu inceleyerek bakımın sonucunu doğrulama.

Aşağıdaki PHP parçası yalnız önceden erişimi kısıtlanmış yönetim/dağıtım aracında, hedef siteyle aynı OPcache örneğine bağlı çalışma ortamı içindir. Herkese açık bir reset dosyası olarak yayımlamayın. opcache.restrict_api varsa izin verilen script yolu da gereklidir; yol öneki kısıtı kimlik doğrulamasının yerine geçmez:

<?php
if (!function_exists('opcache_reset')) {
    throw new RuntimeException('OPcache API bu ortamda kullanılamıyor.');
}
if (!opcache_reset()) {
    throw new RuntimeException('OPcache reset isteği kabul edilmedi; durumu inceleyin.');
}
echo "Reset isteği kabul edildi; yeni HTTP isteklerinde sürümü doğrulayın.\n";

Şu bağımsız CLI çağrısını web/FPM önbelleğini temizlemek için kullanmayın. CLI önbelleği kapalı olabilir; açık olsa bile normal ayrı CLI süreci web uygulamasının bellek önbelleğini paylaşmaz:

php -r 'opcache_reset();'

Başarılı reset dönüşü, bütün isteklerin yeni sürümü gördüğünü kanıtlamaz. Reset bellek önbelleğini etkiler; ayrı dosya önbelleğini veya zaten çalışmakta olan kodu değiştirmez. Gerçek HTTP yanıtları, sürüm kimliği ve uygulama kontrolleriyle doğrulayın; uzun ömürlü worker’ları ve preload yaşam döngüsünü ayrıca yönetin. FPM master yenilemesinin aynı master’ı paylaşan diğer uygulamaları da etkilediğini planlayın. Kalıcı çözüm, ölçülen kapasite ve yayın/geri dönüş akışının birlikte tasarlanmasıdır.

Resmî reset API belgesi bellek önbelleği kapsamını ve dönüş değerini ayrıntılandırır.

OPcache’i Diğer Sunucu Optimizasyonlarıyla Birlikte Değerlendirin

OPcache yalnız PHP derleme katmanını ele alır. Sonuçları değerlendirirken şu bileşenleri ayrı ayrı inceleyin:

• 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ı

Bu bileşenlerin etkisini aynı iş yükü altında ölçün; OPcache veritabanı sorgularını, ağ gecikmesini veya bütün uygulama maliyetini ortadan kaldırmaz. Bu resmin bütünü için WordPress için sunucu tarafı optimizasyon ve Laravel prod ortam optimizasyonu yazılarımızı birlikte değerlendirebilirsiniz.

DCHost üzerinde kullandığınız hizmette PHP yapılandırmasını kimin yönettiğini, hangi OPcache ayarlarının değiştirilebildiğini ve deploy desteğinin kapsamını doğrulayın. Varsayılan olarak tüm planların aynı modülü veya projeye özel optimizasyon hizmetini sunduğunu varsaymayın. Kendi ölçümleriniz, PHP sürümünüz ve yayın yönteminiz üzerinden bir ayar planı hazırlayın.

Sonraki Adım: Tek Değişkeni Değiştirin ve Sonucu Ölçün

PHP OPcache, önbelleğe alınan kodun yeniden derlenmesini azaltır; etkisi uygulamanın iş yüküne bağlıdır. opcache.enable=1 tek başına kurulum, doğru SAPI, kapasite veya güncel kod garantisi değildir. Bellek, anahtar kapasitesi, zaman damgası denetimi ve CLI davranışını birlikte kontrol edin.

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ı,
• Dosya güncelleme yöntemine göre validate_timestamps stratejilerini,
• 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.

İlk ölçümü kaydedin, bir ayarı değiştirin ve aynı trafik koşullarında kullanılan bellek, anahtar doluluğu, kaçırmalar ve uygulama yanıtlarını karşılaştırın. Yayın ve geri dönüşü doğrulamadan zaman damgası denetimini kapatmayın. Gözlenen darboğaz OPcache dışında kalıyorsa PHP-FPM, veritabanı veya uygulama katmanına odaklanın.