WordPress ve WooCommerce İçin PHP-FPM Ayarları: pm, pm.max_children ve pm.max_requests Hesaplama Rehberi

WordPress ve WooCommerce İçin PHP-FPM Ayarlarını Neden Ciddiye Almalısınız?

WordPress veya WooCommerce ile çalışan bir sitede performans sorunları yaşadığınızda çoğu kişi hemen eklentilere, tema koduna veya veritabanına odaklanır. Oysa PHP-FPM havuz ayarları yanlışsa, en temiz kod ve en güçlü veritabanı bile sizi tam anlamıyla kurtaramaz. Özellikle pm, pm.max_children ve pm.max_requests değerleri; sitenizin aynı anda kaç isteği kaldırabildiğini, RAM’in nasıl kullanıldığını ve uzun süren PHP işlemlerinin sistemi şişirip şişirmediğini doğrudan belirler.

DCHost ekibi olarak sahada en sık gördüğümüz senaryo şu: Sunucu güçlü, PHP versiyonu güncel, veritabanı makul fakat PHP-FPM varsayılan ayarlarda bırakılmış. Sonuç; kampanya dönemlerinde 502/504 hataları, panelde “server reached pm.max_children” logları ve zaman zaman beyaz ekran. Bu rehberde, WordPress ve WooCommerce için PHP-FPM ayarlarının mantığını sade bir dille anlatacağız ve RAM’inize, trafiğinize ve senaryonuza göre pm, pm.max_children ve pm.max_requests değerlerini adım adım nasıl hesaplayacağınızı göstereceğiz.

Anlatımda hem tek WordPress siteli basit bir VPS, hem de yoğun trafikli WooCommerce mağazası örneklerini kullanacağız. Böylece kendi sitenize en yakın senaryodan başlayıp, zamanla ince ayar yapabilirsiniz.

PHP-FPM Temel Kavramlar: pm, pm.max_children ve pm.max_requests

PHP-FPM havuzu nedir?

PHP-FPM, PHP kodunu işleten bir servis; her domain veya site için havuz (pool) tanımlayabilirsiniz. Örneğin /etc/php-fpm.d/www.conf veya benzeri bir dosyada [www] isimli havuz, çoğu zaman tüm siteleri çalıştırır. Gelişmiş kurulumlarda her site veya proje için ayrı havuz açıp, kaynakları daha net izole etmek mümkündür.

Her havuz içinde, PHP isteklerini karşılayan child process (alt süreçler) bulunur. İşte pm, pm.max_children ve pm.max_requests bu child süreçlerin sayısını ve yaşam döngüsünü yönetir.

pm (process manager) nedir, hangi modlar var?

pm ayarı, havuzdaki süreçleri nasıl yöneteceğini belirleyen ana anahtardır. Üç temel mod vardır:

• pm = static: Başlangıçta belirlediğiniz kadar süreç açılır ve sayısı sabit kalır. Öngörülebilir ama esnek değildir, daha çok yüksek ve stabil trafik için uygundur.
• pm = dynamic: Belirlediğiniz minimum ve maksimum yedek süreç sayısına göre, trafiğe bakarak süreçleri artırıp azaltır. WordPress ve WooCommerce için genelde en mantıklı ve dengeli seçenek budur.
• pm = ondemand: Başta süreç açmaz; istek geldikçe süreç oluşturup, belirli süre kullanılmayınca kapatır. RAM’i agresif tasarruf eder, düşük trafikli siteler için idealdir ama ani yüklerde gecikmeye neden olabilir.

pm.max_children ne işe yarar?

pm.max_children, aynı anda ayakta olabilecek en fazla PHP-FPM child sayısını belirler. Başka bir ifadeyle:

“Aynı anda en fazla kaç PHP isteği işlenebilir?”

Bu değer çok düşük olursa yoğunluk anlarında istekler kuyruğa girer, kullanıcılar yavaşlık hisseder ve gateway timeout (504) hataları görebilirsiniz. Çok yüksek olursa, her child işlem RAM tükettiği için sunucuyu bellekten boğarsınız; swap’e düşer, tüm sistem ağırlaşır veya çöker.

Bu yüzden pm.max_children her sunucu için RAM’e göre hesaplanmalıdır. Az sonra bunun formülünü ve pratik örneklerini anlatacağız.

pm.max_requests neden önemli?

pm.max_requests, her bir PHP-FPM child sürecinin, öldürülüp yeniden oluşturulmadan önce en fazla kaç isteği işleyebileceğini belirler. Bunun iki temel faydası vardır:

• Uzun süre çalışan süreçlerde biriken memory leak (sızıntı) veya geçici şişmenin temizlenmesi
• Belli sayıda istekten sonra süreçleri yenileyerek, daha stabil ve tahmin edilebilir RAM kullanımı sağlamak

Çok düşük ayarlanırsa süreçler sürekli yeniden başlar, bu da gereksiz overhead yaratır. Çok yüksek ayarlanırsa, zamanla şişen süreçler RAM’i doldurabilir. WooCommerce gibi ağır eklentili sitelerde genelde 300–1000 aralığı sağlıklı bir başlangıçtır.

Hesaba Başlamadan Önce: RAM Bütçesini Doğru Belirlemek

Doğru pm.max_children değerini bulmak için önce şu soruya cevap vermelisiniz:

“Toplam RAM’in ne kadarını PHP-FPM süreçlerine ayırabilirim?”

Çünkü sunucuda sadece PHP çalışmıyor; aynı makinada genellikle aşağıdakiler de var:

• Web sunucusu (Nginx, Apache veya LiteSpeed)
• Veritabanı (MySQL/MariaDB)
• Önbellek sunucusu (Redis, Memcached)
• SSH, sistem servisleri ve işletim sistemi çekirdeği

Bu yüzden RAM’i kabaca bölmek gerekir. Yeni sunucular için genel kaynak planlamasını nasıl yapmanız gerektiğini merak ediyorsanız, CPU, RAM ve trafik hesaplama rehberimizi mutlaka inceleyin.

WordPress ve WooCommerce için örnek RAM dağılımı

Elbette her projeye göre değişir ama sahada sık kullandığımız bazı basit oranlar şöyle:

• 4 GB RAM’li küçük WordPress sitesi
  • 1 GB → İşletim sistemi + temel servisler
  • 1.2 GB → MySQL/MariaDB
  • 0.3 GB → Nginx/Apache + diğer ufak servisler
  • 1.5 GB → PHP-FPM süreçleri
• 8 GB RAM’li WooCommerce mağazası
  • 1.5 GB → İşletim sistemi + temel servisler
  • 2.5 GB → MySQL/MariaDB (daha geniş innodb_buffer_pool)
  • 0.5 GB → Nginx/Apache + Redis
  • 3.5 GB → PHP-FPM süreçleri

WooCommerce özelinde daha detaylı kapasite hesabı için, WooCommerce kapasite planlama rehberimizde vCPU, RAM ve IOPS tarafını derinlemesine anlattık. Bu yazıda ise doğrudan PHP-FPM havuzuna odaklanıyoruz.

Adım Adım Hesaplama: pm.max_children Değerini Nasıl Buluruz?

Genel formül şu:

pm.max_children = PHP için ayırdığınız RAM (MB) / Tek bir child sürecin ortalama RAM tüketimi (MB)

Buradaki kilit nokta, “tek bir child sürecin ortalama RAM tüketimi” değerini gerçeğe yakın tespit etmek. Bunu tahmini değil, ölçerek yapmanız en sağlıklısıdır.

1. Tek bir PHP-FPM child işleminin ortalama RAM tüketimini ölçmek

Önce sitenizi gerçekçi bir yük altında çalıştırmanız gerekiyor. Yani:

• Siteye birkaç tarayıcı sekmesiyle gezinmek
• WooCommerce ise: ürün listeleme, filtreleme, sepet, ödeme sayfası akışını denemek
• Varsa kampanya sayfaları, arama, blog yazıları vb. sayfaları dolaşmak

Bu esnada sunucuda aşağıdaki gibi bir komutla PHP-FPM süreçlerini izleyebilirsiniz (dağıtıma ve PHP sürümüne göre isim değişebilir):

ps -o pid,cmd,%mem,rss -C php-fpm8.1

rss sütunu, süreçlerin kullandığı RAM’i kilobayt cinsinden gösterir. Örneğin çıktının ortalama değerleri şöyle olsun:

• Child süreçlerin çoğu: rss ≈ 220000 KB (≈ 220 MB)

Bu durumda, tek bir child sürecin ortalama RAM tüketimi ≈ 220 MB diyebilirsiniz. WooCommerce’te yoğun eklenti kullanımında 250–350 MB görmek şaşırtıcı değildir; sade bir blogda ise 80–150 MB aralığına inilebilir.

Bu ölçümü, tema değişikliği, büyük eklenti kurulumları veya WooCommerce tarafında ciddi değişikliklerden sonra tekrarlamak önemlidir.

2. PHP için ayırdığınız RAM’i netleştirmek

Önce toplam RAM’i ve diğer servislerin tüketimini görüp, PHP için ayırabileceğiniz bütçeyi netleştirin:

free -m

veya

htop

ile sistem yükünü izleyebilirsiniz. Varsayalım 8 GB RAM’li WooCommerce sunucunuzda, gözlemlerinizden yola çıkarak:

• OS + sistem servisleri: ≈ 1.5 GB
• MySQL/MariaDB: ≈ 2.5 GB
• Nginx + Redis vb.: ≈ 0.5 GB

Toplam ≈ 4.5 GB ediyor. Size yaklaşık 3.5 GB (3500 MB) kalıyor. Bu 3.5 GB’ı PHP-FPM süreçlerine ayırabilirsiniz.

3. Formül: pm.max_children hesabı

Elimizde:

• PHP için ayrılan RAM: 3500 MB
• Tek child için ortalama RAM: 220 MB

O halde:

pm.max_children = floor(3500 / 220) ≈ floor(15.9) = 15

Yani bu sunucuda, PHP-FPM havuzunuz için pm.max_children = 15 makul bir başlangıçtır. İlerleyen süreçte gerçek trafiği gözleyip, 12–18 aralığında ince ayar yapabilirsiniz.

Örnek 1: 4 GB RAM’li orta trafikli WordPress blog

Senaryo:

• Günde 5–10 bin sayfa görüntüleme
• Önbellek eklentisi (full-page cache) etkin
• Veritabanı aynı sunucuda

Ölçümler:

• OS + servisler: ≈ 1 GB
• MySQL/MariaDB: ≈ 1.2 GB
• Web sunucusu ve diğerleri: ≈ 0.3 GB
• PHP’ye ayırabileceğiniz RAM: ≈ 1.5 GB (1500 MB)
• Child başına RAM (ölçülmüş): ≈ 120 MB

Hesap:

pm.max_children = floor(1500 / 120) ≈ floor(12.5) = 12

Bu durumda başlangıç için:

• pm = dynamic
• pm.max_children = 12

değerleri gayet sağlıklı olur.

Örnek 2: 8 GB RAM’li WooCommerce mağazası

Senaryo:

• Günde 20–40 bin sayfa görüntüleme
• Kampanya döneminde eş zamanlı 50+ kullanıcı
• Sepet ve ödeme adımlarında dinamik içerik yoğun

Ölçümler:

• PHP’ye ayırabileceğiniz RAM: 3.5 GB (3500 MB)
• Child başına RAM (ölçülmüş): ≈ 250 MB

Hesap:

pm.max_children = floor(3500 / 250) = floor(14) = 14

Daha agresif oynamak istiyorsanız 15–16’ya çıkabilirsiniz ama RAM sınırına yaklaşacağınız için, mutlaka canlı izleme yapmanız gerekir.

pm Modu Seçimi: static mi, dynamic mi, ondemand mı?

pm.max_children kadar önemli bir diğer karar da pm modudur. WordPress ve WooCommerce için sahada en pratik yaklaşım şöyle:

pm = dynamic: Çoğu WordPress/WooCommerce için önerilen mod

Dynamic mod, trafiğe göre child sayısını ayarladığı için genelde en dengeli seçenektir. Bu modda ayrıca şu ayarlar devreye girer:

• pm.start_servers: Servis başladığında kaç child açılsın?
• pm.min_spare_servers: Boşta en az kaç child dursun?
• pm.max_spare_servers: Boşta en fazla kaç child dursun?

Örneğin pm.max_children = 12 olan bir WordPress blog için:

• pm.start_servers = 3
• pm.min_spare_servers = 2
• pm.max_spare_servers = 6

gibi değerler, hem RAM tasarrufu sağlar hem de aniden gelen 3–4 isteği bekletmeden karşılamaya yardımcı olur.

pm = ondemand: Düşük trafikli siteler için RAM dostu seçenek

Düşük trafikli kurumsal site veya kişisel bloglarda, sunucunuzda başka projeler de çalışıyorsa pm = ondemand kullanmak mantıklı olabilir. Bu modda:

• İstek yokken child süreç yoktur (RAM harcanmaz).
• İstek geldikçe süreç açılır.
• pm.process_idle_timeout süresi dolunca boşta süreçler kapatılır.

Bu modun handikapı, ani trafik patlamalarında ilk birkaç istekte ek gecikmelerdir, çünkü süreçler sıfırdan oluşturulur. WooCommerce gibi ödeme kritik iş yüklerinde genellikle dynamic mod daha güvenlidir.

pm = static: Yüksek ve sabit trafikli, izole ortamlarda

pm = static, child sayısını sabitleyip trafiğe göre asla oynatmaz. Büyük haber siteleri, yoğun API sunucuları veya çok iyi tanıdığınız bir WooCommerce yükü için kullanılabilir. Avantajı, davranışın aşırı öngörülebilir olmasıdır; dezavantajı ise boşta RAM tüketimini azaltamamanızdır.

pm.max_requests Değerini Nasıl Belirlemeliyim?

pm.max_requests için evrensel tek bir doğru yok, ama bazı pratik aralıklar var.

Genel mantık şöyle:

• WordPress çekirdeği kendi başına çok sızdıran bir yapı değildir ama eklentiler, tema ve özel kodlar uzun süre çalışan süreçlerde hafıza sızıntısına neden olabilir.
• Bunu sınırlamak için, her child süreç belirli sayıda isteği işledikten sonra kapatılır ve yenisi açılır.

Önerdiğimiz başlangıç aralıkları:

• Sade WordPress blog: 500–1000
• Orta ölçekli WooCommerce: 300–600
• Çok eklentili, ağır WooCommerce: 200–400 (RAM dalgalanmasını izleyerek)

Sahada sık kullandığımız değerler:

• WordPress blog: pm.max_requests = 800
• WooCommerce: pm.max_requests = 400

Zamanla top, htop ve PHP-FPM loglarını izleyerek bu değerleri bir tık yukarı veya aşağı çekebilirsiniz.

WordPress ve WooCommerce İçin Örnek PHP-FPM Havuz Ayarları

Aşağıda tipik iki senaryo için örnek www.conf havuz ayarlarını göreceksiniz. Değerler doğrudan kopyala-yapıştır için değil, referans olması için verilmiştir.

Örnek 1: 4 GB RAM, sade WordPress blog (dynamic)

[www]
user = www-data
group = www-data
listen = /run/php-fpm.sock

pm = dynamic
pm.max_children = 12
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 800

; Performans ve debug için önerilen bazı ayarlar
request_terminate_timeout = 60s
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/www-slow.log

Bu yapı, iyi bir sayfa önbellekleme (full-page cache) ile birleştiğinde, 4 GB RAM’li bir VPS’te oldukça konforlu bir WordPress deneyimi sağlayabilir. Sunucu tarafı optimizasyonun tamamını ele aldığımız WordPress için sunucu tarafı optimizasyon rehberimizi de mutlaka okumanızı öneririz.

Örnek 2: 8 GB RAM, WooCommerce mağazası (dynamic)

[www]
user = www-data
group = www-data
listen = /run/php-fpm.sock

pm = dynamic
pm.max_children = 14
pm.start_servers = 4
pm.min_spare_servers = 3
pm.max_spare_servers = 8
pm.max_requests = 400

request_terminate_timeout = 90s
request_slowlog_timeout = 7s
slowlog = /var/log/php-fpm/www-slow.log

Burada request_terminate_timeout değerini WooCommerce tarafında büyük sepetler ve ağır sorgular için biraz daha yüksek tuttuk. Ancak çok büyütmek, hatalı veya sonsuz döngüye giren script’lerin sistemi kilitlemesine izin verebilir; bu dengeyi iyi takip etmek gerekir.

Gerçek Trafikte Ayarları Doğrulama ve İnce Ayar

Teoride her şey güzel ama canlı trafikte ne olduğunu görmeden doğru ayarı bulmuş sayılmazsınız. Kontrol etmeniz gereken temel noktalar:

1. PHP-FPM loglarında pm.max_children uyarıları var mı?

Örneğin:

server reached pm.max_children setting (14), consider raising it

gibi satırlar görüyorsanız, yoğun anlarda PHP-FPM tüm child’larını dolu kullanıyor ve yeni gelen istekleri bekletiyor demektir. Bu durumda:

• Önce RAM kullanımını kontrol edin (swap’e düşüyor musunuz?).
• RAM elveriyorsa pm.max_children değerini 1–2 artırmayı düşünebilirsiniz.
• RAM sınırında iseniz, tam sayfa önbelleği, nesne önbelleği (Redis) ve sorgu optimizasyonu ile yükü hafifletmeye çalışın.

2. RAM kullanım grafikleri stabil mi?

pm.max_requests ile child’ları düzenli aralıklarla yenilemeniz, RAM kullanımının zaman içinde merdiven gibi sürekli artmasını engellemeli. Eğer RAM şöyle davranıyorsa:

• Gün boyu yavaş yavaş artıyor, gece de düşmüyor
• Swap kullanımına sık sık dokunuyor

o zaman pm.max_requests değerini biraz düşürüp (örneğin 800 → 500, 400 → 300 gibi) yeniden izlemek mantıklı olur.

3. 502/504 hataları ve TTFB değerleri

Yüksek TTFB (ilk bayta kadar geçen süre) ve zaman zaman yaşanan 502/504 hataları çoğu zaman PHP-FPM ve backend kaynaklıdır. Bu konuda daha geniş bakış açısı için, WordPress ve PHP sitelerde yüksek TTFB sorunlarının nedenlerini ve çözümlerini anlattığımız rehbere göz atabilirsiniz.

Ayrıca sayfa hızını sadece hissiyatla değil, veriyle ölçmek için GTmetrix, PageSpeed Insights ve WebPageTest rehberimizde anlattığımız metodları kullanmanızı öneririz.

Paylaşımlı Hosting, VPS ve dedicated sunucuda PHP-FPM Ayarları

Buraya kadar anlattıklarımız, VPS veya dedicated sunucu üzerinde tam yetkiye sahip olduğunuz senaryolar için birebir geçerli. Peki paylaşımlı hosting tarafında durum ne?

Paylaşımlı hostingte durum

Paylaşımlı hosting paketlerinde PHP-FPM havuzları çoğu zaman sağlayıcı tarafından merkezi olarak yönetilir. DCHost’ta da, aynı sunucuda yüzlerce hesabın bir arada sağlıklı çalışması için pm, pm.max_children vb. değerler sistem genelinde optimize edilir. Bu nedenle:

• cPanel veya Plesk üzerinden bu değerleri doğrudan değiştiremezsiniz.
• Buna karşılık, opsiyonel PHP versiyonu, memory_limit, max_execution_time gibi site bazlı ayarları kontrol edebilirsiniz.

Eğer siteniz paylaşımlı hosting sınırlarını zorluyorsa, sıklıkla “resource limit reached” benzeri hatalar görüyorsanız; bir noktadan sonra en sağlıklı çözüm, paylaşımlı hosting’ten VPS’e sorunsuz geçiş rehberimizde anlattığımız şekilde, sitenizi DCHost VPS veya dedicated altyapımıza taşıyıp PHP-FPM havuzunu tamamen kendi ihtiyaçlarınıza göre ayarlamak olacaktır.

VPS ve dedicated senaryosu

VPS veya fiziksel sunucuda;

• Her siteye ayrı havuz açabilir,
• Her havuzun pm, pm.max_children ve pm.max_requests değerlerini ayrı ayrı hesaplayabilir,
• Ayrıca OPcache, Redis, MySQL/InnoDB ayarlarını da iş yüküne göre ince ayarlayabilirsiniz.

PHP 8.x gibi daha yeni sürümlere geçerken, FPM havuz ayarlarının da gözden geçirilmesi şart. Bu geçişi planlarken PHP 8.x yükseltme kontrol listesi yazımızdaki FPM havuz önerilerini de referans alabilirsiniz.

DCHost Üzerinde WordPress/WooCommerce İçin Pratik Öneriler

DCHost altyapısında WordPress ve WooCommerce müşterileriyle çalışırken en verimli sonuçları genellikle şu yaklaşımla alıyoruz:

• 1) Doğru plan ve altyapı seçimi: WooCommerce veya yüksek trafikli bloglar için NVMe diskli VPS veya dedicated sunucular, FPM havuzunun nefes almasını sağlar.
• 2) OPcache + FPM birlikteliği: OPcache’i etkinleştirip, FPM süreçlerinin aynı kodu tekrar tekrar compile etmesini engelleyin. Bu sayede child başına RAM tüketimi de daha tahmin edilebilir olur.
• 3) Nesne önbelleği (Redis) kullanımı: Özellikle WooCommerce’te transient ve sorgu yükünü hafifletmek için kalıcı nesne önbelleği büyük fark yaratır.
• 4) Veritabanı tuning: WooCommerce için MySQL/InnoDB tuning rehberimizde anlattığımız ayarlarla gereksiz yavaş sorguları temizlemek, FPM süreçlerinin daha kısa yaşamasını sağlar.
• 5) Yedekleme ve test ortamı: FPM ve diğer ayarları denemeden önce sağlam bir yedek stratejinizin olması önemli. Bu konuda WordPress yedekleme stratejileri yazımızdan yararlanabilirsiniz.

Sonuç: Formülden Pratiğe, PHP-FPM Ayarlarını Kontrol Altına Almak

Özetlersek; WordPress ve özellikle WooCommerce için PHP-FPM ayarları, “varsayılana bırakılacak” detaylar değil. pm, pm.max_children ve pm.max_requests değerleri doğrudan:

• Aynı anda kaç isteği kaldırabildiğinizi,
• RAM’in nasıl kullanıldığını,
• 502/504 hatalarının ne kadar sık görüleceğini,
• Yoğun trafik anlarında sitenin nefes alıp alamayacağını

belirliyor. Doğru yaklaşım; önce RAM bütçesini ve child başına gerçek RAM tüketimini ölçmek, ardından pm.max_children değerini formülle çıkarıp, pm modunu (çoğu zaman dynamic) seçerek işe başlamak. Sonrasında loglar, RAM grafikleri ve TTFB ölçümleriyle birkaç iterasyon daha yaparak ideal denge noktasını bulmak.

Eğer DCHost üzerinde WordPress veya WooCommerce çalıştırıyor ve bu rehberi okurken aklınızda hâlâ soru işaretleri kaldıysa, altyapınızı birlikte inceleyip size özel bir FPM planı çıkarabiliriz. Sunucunuz ister paylaşımlı, ister VPS, ister dedicated olsun; doğru PHP-FPM ayarlarıyla çok daha stabil, hızlı ve öngörülebilir bir ortam elde etmek mümkün. Bir sonraki adımda, bu ayarları canlıya almadan önce küçük bir staging ortamında denemenizi; bunun için de WordPress staging ortamı kurma rehberimizi kullanmanızı tavsiye ederiz.

Doğru yapılandırılmış bir PHP-FPM havuzu, yalnızca bugünün performans sorunlarını çözmekle kalmaz; trafik arttığında, kampanyalar çoğaldığında ve siteniz büyüdüğünde de güvenle ölçeklenmenizi sağlar.