PHP-FPM

PHP-FPM (FastCGI Process Manager); PHP’nin resmi olarak sunduğu, yüksek trafikli uygulamalar için geliştirilmiş process yöneticisidir. Nginx + PHP-FPM ikilisi, modern LAMP/LEMP yığınının de facto standardıdır: WordPress, Laravel, Magento, Nextcloud ve bunlar gibi PHP tabanlı tüm kurumsal uygulamalar bu kombinasyonla çalışır.

PHP-FPM’in güçlü özelliği pool modelidir: uygulamalar için ayrı worker havuzları ve Unix kullanıcıları tanımlanabilir. Havuz ayrımı tek başına tam kaynak izolasyonu sağlamaz; ortak sunucudaki bellek veya CPU tükenmesi diğer uygulamaları etkileyebilir. Gerekirse ayrı servisler, konteynerler ve işletim sistemi kaynak sınırları kullanılır.

Mono’nun yaklaşımı

• PHP sürümü: Uygulamayla uyumlu ve desteklenen sürüm seçilir. Destek dışı PHP’yi ayrı pool’a almak güvenlik güncellemesinin yerine geçmez.
• pm modu: dynamic - pm.min_spare_servers, pm.max_spare_servers, pm.max_children yük testine göre kalibre.
• OPcache: Kod yenileme davranışı deploy stratejisine bağlanır. CLI’dan yapılan reset’in çalışan FPM cache’ini temizlediği varsayılmaz.
• Slow log: request_slowlog_timeout = 5s; yavaş endpoint tespiti için /var/log/php-fpm/slow.log.
• Güvenlik: cgi.fix_pathinfo=0; her pool kendi sistem kullanıcısıyla çalışır (www-data yerine uygulama-spesifik).
• Bağlantı: Aynı host’ta Unix socket ve izinleri; ayrı host/konteynerlerde sınırlanmış TCP erişimi değerlendirilir.

Nginx ile FastCGI bağlantısı

Aşağıdaki parça bir örnektir; socket yolu, PHP sürümü ve uygulamanın front-controller kuralları ortama göre düzenlenir. Yüklenen dosyaların PHP olarak çalıştırılmaması ayrıca güvence altına alınmalıdır. Bu örnek tek başına tam bir güvenli sanal host yapılandırması değildir.

location ~ \.php$ {
    try_files $uri =404;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
    include fastcgi_params;
    fastcgi_read_timeout 60;
    fastcgi_buffers 16 16k;
    fastcgi_buffer_size 32k;
}

Yaygın sorunlar ve çözümler

• 502 Bad Gateway: PHP-FPM servisi düşmüş ya da socket yolu yanlış. systemctl status php8.3-fpm ve socket yolunu doğrula.
• “max_children reached” uyarısı: pm.max_children yetersiz veya bir request sızdırıyor. Slow log ile uzun süren request’i bul; max_children artırmadan önce nedeni çöz.
• Bellek tükenmesi: OPcache memory_consumption yetersiz (opcache.memory_exhausted istatistiklerde görünür) veya process başına bellek fazla. pm.max_requests ile periyodik worker yenileme yap.
• Yavaş uygulama: Slow log, veritabanı sorguları ve dış servis beklemeleriyle darboğaz ayrılır. Timeout artırmak sorguyu hızlandırmaz.
• Session çakışması çok-pool ortamında: Her pool için ayrı session.save_path tanımla.

pm.max_children için kapasite planı

Worker sayısının bellek bütçesine göre hesaplanması başlangıç noktasıdır, kesin sonuç değildir. PHP process’lerinin paylaşılan bellek kullanımı ve istekler arasındaki farklar ölçümü etkiler. Dosya işleme veya rapor üretimi yapan endpoint’ler, basit API isteklerinden çok daha fazla bellek tüketebilir. Ortalama değere dayanarak bütün RAM’i worker’lara ayırmak OOM riskini büyütür.

Hesapta işletim sistemi, OPcache, diğer servisler ve güvenlik payı ayrılır. Sonrasında kuyruk uzunluğu, aktif/boş worker sayısı ve max children reached uyarıları yük altında izlenir. Veritabanının bağlantı sınırı da dikkate alınır: fazla worker, dar bir bağlantı havuzunda yalnızca daha fazla bekleyen süreç oluşturabilir.

OPcache ve sürüm geçişi

opcache.validate_timestamps=0 kullanıldığında yeni PHP dosyalarının yayınlanması tek başına yeterli değildir. Aktif FPM süreçlerinin yeni kodu hangi mekanizmayla yükleyeceği tanımlanmalıdır. Kontrollü FPM yeniden yükleme veya yeni konteynerlere trafik taşıma gibi yöntemler denenebilir. CLI ile FPM farklı çalışma bağlamlarıdır; CLI üzerinden opcache_reset() çağırmak FPM’in kullandığı cache’i temizlediği anlamına gelmez.

Kod, statik dosyalar ve veritabanı değişikliklerinin uyumluluğu korunur. Eski ve yeni worker’ların kısa süre birlikte çalışabileceği düşünülmelidir. Rollback yalnızca dosyaları geri koymak değil, çalışan süreçleri ve cache durumunu da önceki sürümle tutarlı hâle getirmektir.

PHP-FPM’de kalmak mı, FrankenPHP’ye geçmek mi?

PHP-FPM mevcut uygulamalarda olgun ve anlaşılır bir işletim modeli sunar. FrankenPHP worker mode ise başlangıç maliyeti yüksek uygulamalarda değerlendirilir; istekler arası durum temizliği ve eklenti uyumluluğu ayrıca test edilir. Mono’nun yaklaşımı önce yavaşlığın kaynağını bulmak, sonra runtime kararını ölçülen gecikme, bellek ve bakım maliyetiyle vermektir. Her sorun yeni bir uygulama sunucusu gerektirmez.

İlgili hizmetlerimiz

Sıkça sorulan sorular