Yük Altında Çalışan Sistemlerde Gerçek Darboğaz Nginx Değil PHP-FPM’dir

Sunucu yönetiminde en sık karşılaştığım yanlış varsayımlardan biri şudur:

“Nginx hızlı, o yüzden sistem ölçeklenir.”

Gerçekte production ortamında Nginx neredeyse hiçbir zaman asıl problem değildir. Asıl problem çoğu zaman PHP-FPM, upstream queue yönetimi ve request lifecycle’ın yanlış anlaşılmasıdır.

Bu yazıda yüksek trafikli sistemlerde yaşanan gerçek bottleneck noktalarını ve production’da gördüğüm örnekleri anlatacağım.

---

İlk Yanılgı: CPU Kullanımı = Problem

Bir sistem yavaşladığında ilk bakılan yer genelde CPU olur.

top

Ama production’da CPU %30 iken bile sistem “ölü gibi” hissedebilir.

Çünkü gerçek problem çoğu zaman CPU değil:

• Request queue
• Worker saturation
• IO wait
• Slow upstream response

---

Nginx Sadece Trafiği Yönlendirir

Nginx’in görevi:

• Request almak
• PHP-FPM’e iletmek
• Response’u geri döndürmek

Ama Nginx şunu yapmaz:

• PHP kodunu hızlandırmaz
• Database sorgusunu optimize etmez
• Deadlock çözmez

Yani Nginx hızlıysa sistem hızlı değildir, sadece “trafik hızlı geçiyordur”.

---

Asıl Darboğaz: PHP-FPM Worker Sayısı

Production’da en sık gördüğüm problem şudur:

pm.max_children = 10

Bu değer düşük olduğunda:

• Request queue büyür
• Nginx 502 üretir
• Kullanıcı tarafında timeout başlar

Ama sistem loglarında her şey “normal” görünür.

---

Sessiz Katil: Request Queue

PHP-FPM tarafında worker dolduğunda istekler queue’ya girer.

Bu durum:

• CPU yükseltmez
• RAM patlatmaz
• Ama sistem “yavaşlar”

En tehlikeli problem türü budur çünkü monitoring bunu geç fark eder.

---

Slow Log Olmadan Debug Yapmak Körlüktür

Bir sistemde slow log yoksa şunu yapıyorsun:

Problemi tahmin ediyorsun.

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

Bu log bana birçok production probleminde gerçek sebebi gösterdi:

• Deadlock query’ler
• External API beklemeleri
• Infinite loop’lar
• Cache miss zincirleri

---

Database Çoğu Zaman Suçlu Değildir

Yanlış bir algı var:

Sistem yavaşsa DB suçludur.

Gerçekte:

• Cache yanlış kullanılmış olabilir
• Connection pool dolmuş olabilir
• Query index’ler eksik olabilir
• ORM gereksiz query üretiyor olabilir

Ama en kritik nokta şudur:

DB değil, DB’ye giden pattern bozuk olabilir.

---

Keepalive ve Connection Reuse Problemi

Nginx tarafında keepalive doğru ayarlanmazsa:

• Her request yeni TCP connection açar
• TLS handshake maliyeti artar
• Latency yükselir

keepalive_timeout 65;
keepalive_requests 1000;

Bu küçük ayarlar bile yüksek trafikte ciddi fark yaratır.

---

Production Gerçeği: Sorun Tek Noktada Değil

En büyük öğrenimlerden biri şu oldu:

Sistem problemleri genelde tek bir hatadan oluşmaz.

Örnek zincir:

• Küçük bir slow query
• PHP worker beklemesi
• Queue büyümesi
• Nginx timeout
• Kullanıcı error görmesi

Aslında sorun bir yerde başlar, başka yerde görünür.

---

Rate Limit Yanlış Kullanılırsa Sistemi Daha Kötü Yapar

Rate limit iyi bir güvenlik aracıdır ama yanlış kullanılırsa:

• Legit kullanıcıları engeller
• API sistemlerini bozar
• Cache hit ratio düşürür

limit_req zone=api burst=20 nodelay;

Bu yapı her sistem için uygun değildir.

---

En Kritik Nokta: Gözlemleme Yeteneği

Zamanla şunu öğrendim:

İyi sistem yöneticisi problemi hızlı çözen değil, problemi erken gören kişidir.

Bunun için:

• Request tracing
• Log correlation
• Metrics + logs birlikte analiz
• Baseline oluşturma

gerekiyor.

---

Sonuç

Nginx, PHP-FPM veya herhangi bir web stack tek başına sistem performansını belirlemez.

Gerçek performans:

• Worker yönetimi
• Request lifecycle
• Database davranışı
• Cache stratejisi
• Traffic pattern

ile oluşur.

Production’da en önemli şey şudur:

Sistemin nasıl çalıştığını değil, nasıl bozulduğunu anlamak.

Çünkü sistemler her zaman çalışır… sorun çıktığında nasıl davrandığı önemlidir.