Bir PHP uygulamasında istekler yavaşladığında pm.max_children değerini artırmak cazip gelir. Ancak daha fazla çalışan her zaman daha fazla kapasite demek değildir: Her çalışan belleğe ihtiyaç duyar ve aynı anda daha fazla veritabanı bağlantısı açabilir. Doğru sayı, uygulamanın gerçek yükünü ölçerek bulunur.

Önce sürecin sınırını anlayın

PHP-FPM bir havuzdaki eşzamanlı PHP isteği sayısını sınırlar. pm = static sabit sayıda çalışan kullanırken, dynamic belirlenen aralıkta çalışan sayısını ayarlar. ondemand süreçleri ihtiyaç halinde başlatır ve boşta kalanları sonlandırır. pm.max_children üç modelde de üst sınırdır. Bekleyen isteklerin tamamı kaybolmaz; önce mevcut bağlantı kuyruğuna girebilirler. Kuyruğun dolması ve üst katman zaman aşımları ise kullanıcıya hata olarak yansıyabilir.

Bellek için yaklaşık bütçe çıkarın

Örneğin 4 GB RAM olan bir makinede işletim sistemi, veritabanı, Redis ve güvenlik payı için 2,5 GB ayırdığınızı varsayalım. PHP-FPM havuzuna yaklaşık 1,5 GB kalır. Yük altında bir çalışan için gözlediğiniz makul bellek ihtiyacı 75 MB ise 1500 / 75 yaklaşık 20 eder. Bu değer bir performans garantisi değil, ölçüme başlanacak üst sınıra ilişkin kaba bir tahmindir. Büyük isteklerde bellek tüketimi artabilir ve birden fazla havuz aynı belleği paylaşır.

RSS değerlerini doğrudan toplayınca paylaşılan bellek birden çok kez sayılabilir; yalnızca tek bir süreç anlık görüntüsüyle karar vermeyin. Zaman içinde yük altındaki süreçleri, toplam bellek baskısını ve uygulamanın en ağır uç noktalarını birlikte inceleyin.

TERMINALonur@web:~
free -h
ps -eo pid,rss,cmd --sort=-rss | head -n 20
systemctl status php8.3-fpm

Servis adı dağıtıma ve kurulu PHP sürümüne göre farklıdır; örnekteki adı kendi ortamınıza uyarlayın. Üretimde işlem yapmadan önce mevcut ayarı ve geri dönüş yolunu kaydedin.

Bekleme var mı, sadece yavaş işlem mi?

FPM durum sayfasındaki listen queue, boş ve çalışan süreç sayılarıyla birlikte anlam kazanır. max children reached sıfırdan büyükse havuz bir noktada sınıra ulaşmıştır; bunun ne kadar sık gerçekleştiğini ve isteklerin ne kadar sürdüğünü ayrıca izlemeniz gerekir. Durum sayfası süreç bilgileri içerebildiğinden internete açık bırakılmamalı, yalnızca yetkili izleme sistemi veya yerel erişimle korunmalıdır.

Bekleme kuyruğu artıyorsa sebep gerçekten çalışan sayısı mı, yoksa yavaş bir SQL sorgusu mu diye bakın. Bir isteğin süresi beş saniyeden yarım saniyeye düştüğünde aynı çalışan sayısıyla daha fazla istek karşılanabilir. Harici API çağrıları ve kilit beklemeleri de süreçleri meşgul eder.

Değişikliği küçük adımlarla deneyin

Önce ölçüm alın, sonra tek havuzda küçük bir değişiklik yapın. Yapılandırmayı ilgili FPM sürümünün test seçeneğiyle doğrulayın ve servis yönetimini dağıtımınızın belgelerine göre uygulayın. Değişiklikten sonra yanıt sürelerini, veritabanı bağlantılarını, bellek tüketimini ve hata oranını karşılaştırın. Sadece ortalamaya değil, yavaş isteklerin yüzdeliklerine de bakın.

Daha yüksek değer daha iyi sonuç üretmiyorsa eski ayara dönün. Gerçek çözüm bazen ağır sorguları iyileştirmek, arka plan işine taşımak veya uygulama önbelleğini düzenlemektir. Kapasite ayarı bu çalışmaların yerine geçmez.

Kaynaklar: PHP-FPM yapılandırması ve FPM durum sayfası.