PHP Uygulamalarında Performans: OPcache, Önbellek ve Kuyruklar

“PHP yavaş” cümlesini sık duyarım. Oysa ölçtüğümde, yavaşlığın kaynağı neredeyse hiçbir zaman dilin kendisi olmuyor: yanlış ayarlanmış bir PHP sunucusu, sayfa başına yüzlerce veritabanı sorgusu ya da istek sırasında yapılan uzun işler. Bu yazıda yüksek trafikli haber portalları ve canlı veri servislerinde uyguladığım performans adımlarını, etkisi en büyük olandan başlayarak sıraladım.

1. Önce ölçün

Tahminle optimizasyon yapmak zaman kaybıdır. Bir isteğin ne kadar sürdüğünü, kaç sorgu çalıştırdığını ve belleğin nereye gittiğini görmeden işe başlamayın. Geliştirme ortamında bir hata ayıklama çubuğu ya da profil aracı, canlıda ise sunucu günlükleri ve basit zaman ölçümleri çoğu zaman yeterli. Hedefi de baştan koyun: örneğin “ana sayfa önbellekten 100 ms altında, önbelleksiz 300 ms altında”.

2. OPcache gerçekten çalışıyor mu?

OPcache, PHP dosyalarının derlenmiş halini bellekte tutar. Kapalıysa ya da doluysa her istek yüzlerce dosyayı baştan derler. Paylaşımlı sunucularda sık rastladığım bir durum: OPcache açık görünür ama bellek ya da dosya sınırı diğer sitelerle dolmuştur, yeni sitenin hiçbir dosyası önbelleğe girmez.

• opcache.memory_consumption ve opcache.max_accelerated_files değerlerini projenin dosya sayısına göre ayarlayın.
• Mümkünse siteye ayrılmış bir PHP-FPM havuzu kullanın; böylece önbellek başka sitelerle paylaşılmaz.
• Canlıda opcache.validate_timestamps kapatılabilir; ama o zaman her yayından sonra FPM’i yeniden yüklemeyi unutmayın.

Bu tek ayar, bir projede uygulamanın açılış süresini yaklaşık 110 ms’den 25 ms civarına indirdi.

3. Çatının kendi önbellekleri

Kullandığınız çatının yapılandırma, rota ve şablon önbelleklerini yayın betiğinize ekleyin. Bu önbellekler her istekte dosyaları baştan okuyup derlemek yerine hazır sonuçları kullanır.

Rota önbelleği için tüm rotaların denetleyici sınıflarına bağlı olması en sağlıklı yoldur; anonim işlevler önbellekle beklenmedik davranabilir. Ortam değişkenlerini yalnızca yapılandırma dosyalarında okuyun, kodun geri kalanında yapılandırma değerlerini kullanın.

4. Veritabanı: N+1 ve eksik indeksler

En sık karşılaştığım sorun, bir listedeki her satır için ilişkili kaydın ayrı bir sorguyla çekilmesi (N+1). İlişkili kayıtları tek sorguda önceden yükleyerek (eager loading) çözülür. Geliştirme ortamında tembel yüklemeyi hata sayan bir ayar açarak bu sorunları daha yazarken yakalayabilirsiniz.

5. Uygulama önbelleği: neyi, ne kadar?

Sık okunan ama seyrek değişen veriler (menüler, ayarlar, ana sayfa blokları) önbellek için idealdir. Redis kullanıyorsanız önbelleği etiketlerle gruplayıp ilgili içerik değiştiğinde yalnızca o grubu temizleyebilirsiniz. Önbelleğe model nesnesi yerine dizi ya da basit veri koymak, sürüm güncellemelerinde yaşanabilecek seri hale getirme sorunlarını da önler. Aynı istek içinde tekrar tekrar hesaplanan değerleri istek boyunca bellekte tutmak da küçük ama etkili bir kazançtır.

6. Uzun işleri kuyruğa alın

E-posta göndermek, görsel işlemek, dış bir API’den veri çekmek ya da yapay zekâ modeline istek atmak kullanıcıyı bekletmemeli. Bu işleri kuyruğa atın, kullanıcıya hemen yanıt dönün. Redis tabanlı bir kuyruk ve sürekli çalışan bir işçi (worker) çoğu proje için yeterlidir. Zamanlanmış görevlerin aynı anda iki kez çalışmaması için bir kilit mekanizması kullanmayı unutmayın.

7. Ön yüz: görünen hız

• Görselleri doğru boyutta ve WebP/AVIF biçiminde sunun; ekranın altındakileri tembel yükleyin.
• Vite ile CSS/JS dosyalarını küçültün ve uzun süreli tarayıcı önbelleği verin.
• Yazı tiplerini font-display: swap ile yükleyin, ilk ekrandaki görselin boyutlarını belirtin.
• Sıkıştırmayı (gzip/brotli) sunucu tarafında açın.

Sonuç

Performans, tek seferlik bir ayar değil bir alışkanlıktır. Ölçün, en büyük darboğazı bulun, düzeltin ve tekrar ölçün. Çoğu projede yukarıdaki adımların ilk üçü, yapılan değişikliklerin büyük kısmını oluşturacak kadar fark yaratır.