WordPress’te OPcache ve object cache performansı

WordPress’te OPcache ve object cache performansı, farklı darboğazları hedefler: OPcache PHP kodunun derlenmiş halini bellekte tutar, object cache ise sık kullanılan WordPress verilerini ve sorgu sonuçlarını tekrar üretmeden saklar. Bu yüzden biri kod yürütme süresini, diğeri veritabanı yükünü azaltır; aynı işi yapmazlar. PHP-FPM ile çalışan bir sitede OPcache çoğu istekte temel hız kazancı sağlar, Redis veya Memcached ile kurulan persistent object cache ise özellikle çok sorgulu sayfalarda, aynı menü ve seçenekleri tekrar tekrar çeken kurulumlarda ve yoğun içerik listelerinde fark yaratır. En doğru karar, iki katmanı ayrı ayrı açıp ölçmek, ardından bellek tüketimi, hata günlüğü ve cache ısınma davranışını izlemektir. Yetersiz bellek, yanlış temizleme sırası ya da uygunsuz backend seçimi kazancı azaltabilir; bu yüzden doğrulama olmadan daha hızlı varsayımı yapmamak gerekir.

WordPress’te OPcache ve object cache performansı hangi katmanda etkiler?

OPcache, PHP dosyalarının her istekte yeniden ayrıştırılmasını ve derlenmesini azaltır. WordPress çekirdeği, tema dosyaları ve eklenti kodları PHP olarak çalıştığı için bu katman, neredeyse tüm isteklerin ilk adımına dokunur. Object cache ise veritabanından çekilen veya WordPress tarafından hesaplanan tekrar kullanılabilir nesneleri saklar. Menüler, seçenekler, yazı meta verileri, taksonomi ilişkileri ve bazı sorgu sonuçları bu kapsama girer. Buradaki kritik ayrım şu: OPcache kodu hızlandırır, object cache veri tekrarını azaltır. Sayfa önbelleği ya da CDN ile aynı şey değildir. Bir WordPress sitesi bazı durumlarda güçlü bir page cache ile zaten hızlı görünebilir; buna rağmen yönetim alanı, API istekleri veya oturuma bağlı sayfalarda object cache ve OPcache farkı hala hissedilir.

Redis ve Memcached ne zaman anlamlı olur?

Redis ve Memcached, WordPress object cache için iki ayrı backend seçeneğidir. Performans farkı çoğu sitede sadece ham hız değil, operasyonel uyum üzerinden okunur. Aynı sunucuda doğru ayarlanmış iki backend de yeterince hızlı olabilir; sorun çoğu zaman seçimin kendisinden çok, ağ gecikmesi, bellek yetersizliği, yanlış flush sırası veya aşırı yüklenmiş servislerdir. Bu yüzden seçim yaparken sadece ‘hangisi daha hızlı’ sorusuna bakmak doğru değildir.

Ne zaman kullanılır? Çok tekrar eden veritabanı çağrıları varsa, içerik listeleri ağırsa, admin ve API tarafında da benzer veriler sürekli okunuyorsa persistent object cache anlamlı olur. Ne zaman sınırlı kalır? Trafiği düşük, basit içerikli ve güçlü bir page cache ile çalışan bir sitede ek karmaşıklık, kazançtan fazla olabilir. Uzak Redis örneği, agresif cache temizliği ya da yanlış eklenti seçimi de bu sonucu değiştirebilir.

• Redis, mevcut altyapıda zaten kullanılıyorsa ve izleme tarafı hazırsa mantıklı bir tercih olur.
• Memcached, sade ve geçici cache ihtiyacı olan kurulumlarda yeterli olabilir.
• İki backend de, aslında çözmeye çalıştığınız sorunun page cache mi yoksa object cache mi olduğunu doğru ayırmadığınızda yanlış beklenti üretir.

PHP-FPM neden listenin içinde yer alır?

PHP-FPM, WordPress isteğini hangi worker sürecinin işlediğini belirler. OPcache ortak bellekte dursa da her worker isteği ayrı ayrı yürütür; object cache ise o worker’ın veritabanına ne kadar gideceğini azaltır. Bu yüzden PHP-FPM, cache katmanlarının etkisini görünür kılan platformdur. Worker sayısı yetersizse istekler kuyruklanır, CPU ya da RAM baskısı artarsa cache kazanımı bile gecikmeyi tamamen silemez. Tam tersine, iyi çalışan bir cache katmanı worker başına harcanan süreyi kısaltır ve aynı havuzla daha fazla isteğin işlenmesine yardım eder.

OPcache değişikliği yaptıysanız ya da PHP yapılandırmasını güncellediyseniz, PHP-FPM reload adımı kritik olur. Reload yapılmadan eski ayarlarla ölçüm yaparsanız, yanlış sonuç okuma riski doğar. Bu nedenle cache performansını incelerken PHP-FPM’i altyapının pasif bir arka planı gibi değil, sonuçları etkileyen canlı bir katman gibi değerlendirmek gerekir.

Güvenli uygulama sırası: tek değişkenle ilerle

1. Önce staging ortamında ya da düşük riskli bir bakım penceresinde temel ölçümü alın. Aynı URL’yi birkaç kez çağırın ve TTFB, CPU, sorgu sayısı gibi değerleri not edin.
2. Önce OPcache durumunu kontrol edin. Kapalıysa bir değişiklik olarak yalnız onu açın ve PHP-FPM’i reload edin.
3. İkinci testte aynı sayfayı tekrar çağırın. İlk istekle sonraki istekler arasındaki farkı görün.
4. Sonra persistent object cache backend’ini ekleyin. Redis veya Memcached seçimi ne olacaksa başka bir değişikliği aynı anda yapmayın.
5. Cache’i temizleyin, ardından gerçek ziyaret akışına benzer birkaç istekle ısıtın. Tekrar eden sorguların düşüp düşmediğini kontrol edin.
6. Her iki katman açıkken bile sorun varsa, tema, eklenti, dış API çağrısı veya PHP-FPM kuyruğu gibi başka bir darboğazı arayın.

php -i | grep -i 'opcache.enable|opcache.memory_consumption|opcache.validate_timestamps' redis-cli ping redis-cli info stats | grep -E 'keyspace_hits|keyspace_misses' systemctl reload php-fpm

Bu kontrollerde opcache.enable satırının On görünmesi, redis-cli ping komutunun PONG dönmesi ve Redis istatistiklerinde hit sayısının ısınan trafikte artması beklenir. Memcached kullanıyorsanız benzer mantıkla servis istatistiklerine bakın; normal kabul edilen durum, cache katmanı aktifken tekrar eden isteklerde veritabanına daha az gidilmesidir. Eğer ilk istek yavaş, sonraki istekler belirgin biçimde hızlıysa bu çoğu zaman sağlıklı bir warm-up davranışıdır. Buna karşılık ilk istekten sonra da fark yoksa, cache değil başka bir darboğaz konuşuluyordur.

Cache doğrulama: hızlı sayfa mı, ısınmış cache mi?

Doğrulamada en sağlıklı yöntem, aynı sayfayı aynı ortamda ve benzer trafik koşullarında tekrar etmektir. Tarayıcı önbelleği, CDN, page cache ve arka plandaki cron işleri sonucu bozabilir. Bu yüzden tek bir hızlı yükleme yerine birkaç tekrar ve servis tarafı istatistiği birlikte okunmalıdır.

Geri dönüş planı

Canlıda sorun çıkarsa her şeyi birden kapatmak yerine tek bir değişikliği geri alın. Persistent object cache eklentisi açıldıktan sonra hata üretirse önce onu devre dışı bırakın ve cache’i temizleyin. Redis veya Memcached backend’ini değiştirdiyseniz, uygulamanın artık o servise bağlı olmadığını doğrulayın. OPcache ayarını ini dosyasında değiştirdiyseniz, eski değere dönün ve PHP-FPM’i yeniden yükleyin. Bu sırada siteyi tekrar ölçün; değişiklikten önceki ve sonraki davranışın aynı olduğundan emin olmadan ikinci bir düzenleme yapmayın.

1. Hatanın hangi katmanda başladığını ayırın: OPcache mi, object cache mi, PHP-FPM mi?
2. Persistent object cache eklentisini kapatın ve cache’i temizleyin.
3. OPcache ayarını eski hale getirin, ardından PHP-FPM reload yapın.
4. Yeniden aynı URL’leri test edin ve hata veya gecikme kalıp kalmadığını kontrol edin.

Sık yapılan hatalar

• OPcache ile object cache’i aynı şey sanmak ve yalnız birini açınca her sorunun çözüleceğini düşünmek.
• Redis ya da Memcached’i uzak sunucuda, gecikme ölçmeden kullanmak.
• Canlı trafikte cache temizleyip hemen performans sonucu beklemek; warm-up etkisini hesaba katmamak.
• OPcache değişikliğinden sonra PHP-FPM’i reload etmeden sonuç okumak.
• Tek seferde hem tema, hem eklenti, hem cache backend değiştirmek ve hangi adımın etkili olduğunu kaybetmek.
• Page cache iyi çalışıyor diye object cache ve OPcache etkisini göz ardı etmek.

Canlıya almadan önce kısa kontrol

• Önce baseline ölçüm alındı mı?
• OPcache ve object cache rolleri birbirine karıştırılmadı mı?
• Redis veya Memcached backend’i aynı ağda ve sağlıklı mı?
• PHP-FPM reload sonrası aynı URL tekrar test edildi mi?
• Geri dönüşte kapatılacak tek katman net mi?

Karar notu: Site çok sorgu üretiyorsa ve aynı veriler sık tekrar ediyorsa persistent object cache genelde anlamlıdır; site daha çok PHP kodu çalıştırıyor ama veri tekrarına çok girmiyorsa OPcache daha görünür fayda verir. PHP-FPM ise bu iki katmanın üstünde çalışan istek motorudur, cache değildir. En güvenli seçim, tek tek açıp aynı metriklerle ölçmek ve yalnızca gerçekten etkili olan katmanı canlıda bırakmaktır.