PHP-FPM ve PHP-CGI: üretimde ne değişir

İncelemem istenen yavaş ya da kararsız PHP sitelerinin çoğunda kodda bir sorun yoktur. Sorun, PHP süreçlerinin nasıl başlatıldığı, paylaşıldığı ve sınırlandığıdır.

Farkı tek paragrafta anlatmak

Klasik CGI’de web sunucusu her istek için yeni bir PHP süreci başlatır ve sonra atar. Bu basit ve güvenlidir, ama yavaştır. PHP-FPM (FastCGI Process Manager) birçok isteği karşılayan uzun ömürlü işçilerden oluşan bir havuz tutar; bu da opcode önbelleği, kalıcı bağlantılar ve öngörülebilir bellek kullanımı sağlar.

Asıl özellik havuzlardır

Her site kendi kullanıcısı, sınırları ve ayarlarıyla kendi havuzuna sahip olabilir.

; /etc/php/8.3/fpm/pool.d/example.conf
[example]
user = example
group = example
listen = /run/php/example.sock
listen.owner = www-data
listen.group = www-data

pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 500

request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/example-slow.log

pm.max_children boyutlandırma

Tahmin etmeyin. Gerçek yük altında bir işçinin ortalama belleğini ölçün ve ayırabileceğiniz belleği bu sayıya bölün.

ps --no-headers -o rss -C php-fpm8.3 | awk '{s+=$1; n++} END {print s/n/1024 " MB avg"}'

Sonuç 60 MB ve 2 GB ayırabiliyorsanız tavan yaklaşık 30 işçidir. Bunun üstüne çıkmak yavaş istekleri swap ile takas eder; bu daha kötüdür.

Belirtileri okumak

• 502 Bad Gateway genelde havuzun çöktüğü, soketin eksik olduğu ya da soket izinlerinin yanlış olduğu anlamına gelir.
• 504 Gateway Timeout genelde tüm işçilerin meşgul olduğu anlamına gelir. Zaman aşımını artırmadan önce pm.max_children ve yavaş günlüğe bakın.
• Bellek kullanımının yükselmesi çoğu zaman işçileri yeniden başlatan makul bir pm.max_requests ile çözülür.

Kontrol listesi

1. Site başına bir havuz ve bir sistem kullanıcısı.
2. OPcache açık ve kod tabanına göre boyutlandırılmış.
3. pm.max_children ölçülen bellekten türetilmiş.
4. Yavaş günlük açık ve gerçekten okunuyor.