PHP Session ve Queue İşçileri İçin Ayrı PHP-FPM İşlem Havuzu Kurmak

PHP Session ve Queue İşçilerini Neden Ayırmak Zorundayız?

PHP ile yazılmış modern uygulamalarda (Laravel, Symfony, WooCommerce, özel paneller vb.) aynı sunucuda iki çok farklı iş yükünü bir arada koşturuyoruz: kullanıcı oturumlarını yöneten kısa ömürlü HTTP istekleri ve dakikalarca sürebilen, CPU ve I/O tüketen queue (kuyruk) işçileri. Kapasite analizi veya mimari tasarım toplantılarında grafikleri açtığımızda genelde şunu görüyoruz: kampanya dönemlerinde kuyruk işçileri hızla ölçeklenmiş, PHP-FPM süreci sayısı artmış, ama frontend tarafında oturum açmaya çalışan kullanıcılar 502 hataları veya yavaş yanıtlarla boğuşuyor. Sebep çoğu zaman kötü kod değil; aynı işlem havuzunda birbirine zıt karakterde iki iş yükünü, tek bir kaynak havuzundan besliyor olmamız.

Bu yazıda, DCHost tarafında sıkça kurduğumuz izole havuz mimarisini adım adım anlatacağız: PHP session ağırlıklı istekler için ayrı PHP-FPM havuzları, stateless API istekleri için ayrı havuzlar ve queue işçileri için Supervisor + systemd ile sınırlandırılmış bağımsız bir katman. Amaç, hem son kullanıcıya hızlı yanıt verebilmek, hem de kuyruk işçilerini gönül rahatlığıyla agresif çalıştırabilmek. Yol üzerinde session kilitlenmesi, FPM tıkanması, OOM killer ve CPU patlaması gibi klasik sorunlara da değineceğiz.

Problemin Kökü: Aynı Havuzda Farklı İş Yükleri

Standart bir LEMP/LAMP kurulumunda genellikle tek bir www isimli PHP-FPM havuzu olur. Tüm sanal hostlar bu havuza bağlanır; hem oturum alan kullanıcı istekleri hem de arka planda çalışan işler aynı işlem havuzunu paylaşır. Bu model küçük siteler için fena değildir ama trafik ve iş yükü büyüdüğünde aşağıdaki sorunlar başlar:

• Session kilitlenmesi: Dosya tabanlı ya da Redis tabanlı PHP session’lar, süreç bazında kilitlenebilir. Uzun süren bir istek oturumu açık tuttuğunda, aynı oturuma sahip diğer istekler beklemeye başlar.
• PHP-FPM saturasyonu: Queue işçileri veya ağır rapor istekleri FPM çocuk süreçlerini doldurur; yeni gelen HTTP istekleri bekler, sonunda timeout ile 502/504 üretir.
• OPcache ve memory baskısı: Aynı havuzda onlarca farklı iş, ortak OPcache ve memory limitlerini paylaşır. Büyük queue job’ları, frontend için ayrılan RAM’i sessizce tüketebilir.
• Farklı SLA’ler: Kullanıcı isteği için 300 ms hedeflerken, rapor üreten queue job’unuzun 120 sn çalışması gayet normal olabilir. Tek havuzda ikisini dengelemek zordur.

Bu tabloya, yanlış seçilmiş session ve cache altyapısını da eklerseniz sorun katlanır. Session ve cache tarafındaki seçeneklerin performansa etkisini detaylı olarak anlattığımız PHP session ve cache depolamasını doğru seçme rehberimizi bu yazıdan sonra mutlaka okumanızı öneririz.

Mimari Yaklaşım: İzole Havuz ve İşçi Katmanları

DCHost olarak önerdiğimiz mimariyi iki ana katmana ayırıyoruz:

• 1) PHP-FPM havuz katmanı: HTTP isteklerini karşılayan, Nginx/Apache arkasında çalışan kısa ömürlü süreçler. Burada da kendi içinde session ağırlıklı ve stateless havuzlar açıyoruz.
• 2) Queue işçi katmanı: php-cli ile çalışan, Supervisor ve systemd tarafından yönetilen, FPM’den tamamen bağımsız işçiler. CPU ve RAM limitleri ayrı.

Bu sayede üç önemli hedefe ulaşıyoruz:

• Ön yüzdeki kullanıcı isteklerini, arka plandaki batch işlerden izole etmek.
• Session kilitlenmesini, uzun yaşayan süreçler yüzünden yayılmasını engellemek.
• Kaynakları (CPU, RAM, I/O) hem FPM havuzları arasında hem de kuyruk işçileri ile adil biçimde paylaşmak.

Kuyruk ve arka plan işleri tarafının detaylı genel resmini merak ediyorsanız, adım adım örneklerle anlattığımız VPS üzerinde arka plan işleri ve kuyruk yönetimi yazımız bu makalenin doğal tamamlayıcısıdır.

PHP-FPM ile Session Ağırlıklı ve Stateless Havuzları Ayırmak

Önce HTTP tarafını düzenleyelim. Hedefimiz en az iki ayrı FPM havuzu:

• session_pool: Kullanıcı oturumu yöneten frontend ve admin istekleri. Örneğin WordPress, WooCommerce, geleneksel paneller.
• api_pool: JWT veya token tabanlı, mümkün olduğunca stateless API istekleri.

Bu sayede, API tarafında daha agresif concurrency ayarları kullanabilirken, session havuzunda daha korumacı davranabiliriz.

Örnek PHP-FPM Havuz Konfigürasyonu

Tipik bir Debian/Ubuntu sunucusunda PHP-FPM havuz dosyaları /etc/php/8.2/fpm/pool.d/ altında bulunur. Versiyon ve dağıtıma göre yol değişebilir, mantık aynıdır.

; /etc/php/8.2/fpm/pool.d/session_pool.conf
[session_pool]
user = www-data
group = www-data
listen = /run/php/php8.2-fpm-session.sock
listen.owner = www-data
listen.group = www-data

pm = dynamic
pm.max_children = 30
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10
pm.max_requests = 1000

; Session ağırlıklı havuz - biraz daha uzun timeout
request_terminate_timeout = 60s

; Session handler ve path
php_admin_value[session.save_handler] = redis
php_admin_value[session.save_path] = "tcp://127.0.0.1:6379?database=2"
php_admin_value[session.gc_maxlifetime] = 1440
php_admin_value[session.cookie_httponly] = 1
php_admin_value[session.cookie_secure] = 1

; Slow log
request_slowlog_timeout = 5s
slowlog = /var/log/php8.2-fpm-session.slow.log

; /etc/php/8.2/fpm/pool.d/api_pool.conf
[api_pool]
user = www-data
group = www-data
listen = /run/php/php8.2-fpm-api.sock
listen.owner = www-data
listen.group = www-data

pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 2000

; API genellikle stateless, session kapatılabilir
php_admin_value[session.auto_start] = 0
php_admin_value[session.use_cookies] = 0

request_terminate_timeout = 15s
request_slowlog_timeout = 2s
slowlog = /var/log/php8.2-fpm-api.slow.log

Buradaki bazı kritik noktalar:

• pm.max_children: Havuz başına aynı anda kaç PHP süreci açılacağını belirler. Bunu belirlerken RAM hesabı yapmak zorundasınız. Bu konuda detaylı bir hesaplama rehberine ihtiyacınız varsa, WordPress ve WooCommerce için PHP-FPM ayarları rehberimizde formülleri adım adım anlattık.
• request_terminate_timeout: Session havuzunda biraz daha uzun bırakabilir, API havuzunda agresif kesebilirsiniz. Böylece hatalı veya takılı kalan istekler havuzu kilitlemez.
• session handler: Session havuzunda Redis kullanmak, dosya tabanlı session’a göre çok daha sağlıklı olur. Üstteki ayar bunun basit bir örneği.

Nginx ile Havuzları Sanal Host’lara Bağlamak

Şimdi bu iki havuzu Nginx tarafında doğru sanal host’lara bağlayalım. Örneğin www.site.com session havuzuna, api.site.com ise api havuzuna gitsin:

upstream php_session_pool {
    server unix:/run/php/php8.2-fpm-session.sock;
}

upstream php_api_pool {
    server unix:/run/php/php8.2-fpm-api.sock;
}

server {
    server_name www.site.com;
    root /var/www/site/public;

    location ~ .php$ {
        include fastcgi_params;
        fastcgi_split_path_info ^(.+.php)(/.+)$;
        fastcgi_pass php_session_pool;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

server {
    server_name api.site.com;
    root /var/www/site/public;

    location ~ .php$ {
        include fastcgi_params;
        fastcgi_split_path_info ^(.+.php)(/.+)$;
        fastcgi_pass php_api_pool;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

Bu ayrımın getirileri:

• Frontend’de oturum açan kullanıcılar, uzun süren API isteklerinden etkilenmez.
• API tarafında daha fazla concurrency, daha düşük timeout ve daha agresif FPM ayarları kullanabilirsiniz.
• Slow log ve hata log’larını havuz bazında ayırabildiğiniz için, hangi katmanın sorun çıkardığını çok daha net görürsünüz.

Queue İşçilerini PHP-FPM’den Koparmak: Supervisor + systemd

Birçok Laravel veya Symfony projesinde queue işçileri php-cli ile, genellikle Supervisor tarafından yönetilir. Yani teknik olarak PHP-FPM’in kendisini kullanmazlar. Yine de aynı sunucunun CPU ve RAM’ini tükettikleri için, doğru izole edilmediklerinde FPM havuzlarına ciddi zarar verebilirler. Buradaki hedefimiz:

• Queue işçilerini ayrı bir systemd cgroup’una almak,
• Gerekirse Supervisor’ı bu cgroup içinde koşturmak,
• İşçi sayısı ve memory limitleri ile PHP-FPM havuzunun güvenli sınırlarını korumak.

Supervisor Konfigürasyonu ile Queue İşçileri

Laravel örneği üzerinden gidelim. Supervisor konfigürasyonumuz şöyle olabilir:

; /etc/supervisor/conf.d/laravel-queue.conf
[program:laravel-queue]
process_name=%(program_name)s_%(process_num)02d
command=/usr/bin/php -d memory_limit=512M /var/www/site/artisan queue:work 
    --sleep=1 --tries=3 --queue=default

numprocs=4
autostart=true
autorestart=true
user=www-data
redirect_stderr=true
stdout_logfile=/var/log/supervisor/laravel-queue.log
stopwaitsecs=60

Buradaki kritik noktalar:

• numprocs=4: Aynı anda 4 işçi süreci çalışacak. Bu sayıyı CPU ve RAM bütçenize göre ayarlayın.
• memory_limit=512M: Queue işçileri için PHP memory limitini frontend’den farklı tanımlıyoruz. Böylece ağır job’lar için esneklik sağlarken, limit aşımı durumunda süreçler kontrollü biçimde ölür.
• stdout_logfile: Log’ları ayrı bir yerde tutup, izleme sistemlerine besleyebilirsiniz.

Laravel tarafında queue ve Horizon optimizasyonlarını daha derinlemesine incelemek isterseniz, Laravel prod ortam optimizasyonu rehberimizde gerçek dünya ayar örnekleri bulabilirsiniz.

Supervisor’ı systemd ile İzole Etmek

Supervisor tek başına çalışan bir süreçtir; onu da ayrı bir systemd servisi olarak konumlandırır ve bu servise kaynak limitleri vererek FPM’den ayırırız. Örnek bir unit dosyası:

# /etc/systemd/system/supervisor-queue.service
[Unit]
Description=Supervisor for Laravel Queue Workers
After=network.target

[Service]
Type=simple
User=root
Group=root

ExecStart=/usr/bin/supervisord -n -c /etc/supervisor/supervisord.conf
Restart=always
RestartSec=5

# Kaynak limitleri
CPUAccounting=yes
CPUQuota=150%%
MemoryAccounting=yes
MemoryMax=4G
IOAccounting=yes
IOWeight=200

[Install]
WantedBy=multi-user.target

Açıklamalar:

• CPUQuota=150%: 4 vCPU’lu bir VPS’te bu servis toplam CPU’nun yaklaşık 1.5 çekirdeğine kadar çıkabilir. Böylece kuyruğu hızlandırırken, FPM’e de nefes alanı bırakırız.
• MemoryMax=4G: Queue işçilerinin toplamda 4 GB’tan fazla RAM yemesine izin vermiyoruz. Limit aşılırsa systemd süreçleri öldürür; en azından PHP-FPM’i ve tüm sistemi aşağı çekmezler.
• IOWeight=200: Disk I/O önceliğini ayarlayarak, FPM havuzlarının disk kuyruğunda boğulmasını engelleyebilirsiniz.

Bu servisi etkinleştirmek için:

systemctl daemon-reload
systemctl enable supervisor-queue
systemctl start supervisor-queue

Böylece queue tarafı, PHP-FPM’den hem proses hem de cgroup düzeyinde ayrılmış olur. RAM ve OOM killer davranışının sistem genelinde nasıl işlediğini daha detaylı anlamak isterseniz, VPS’te RAM, swap ve OOM killer yönetimi yazımız tam bu noktada çok faydalı.

Supervisor Yerine Doğrudan systemd Kullanmak

Yeni projelerde pek çok ekip, ek bir bağımlılık kullanmamak için Supervisor yerine doğrudan systemd unit ile Laravel queue işçilerini koşturmayı tercih ediyor. Örneğin:

# /etc/systemd/system/[email protected]
[Unit]
Description=Laravel Queue Worker %i
After=network.target

[Service]
User=www-data
Group=www-data

ExecStart=/usr/bin/php -d memory_limit=512M /var/www/site/artisan queue:work 
    --sleep=1 --tries=3 --queue=default

Restart=always
RestartSec=3

CPUAccounting=yes
CPUQuota=50%%
MemoryAccounting=yes
MemoryMax=1G

[Install]
WantedBy=multi-user.target

Ardından örneğin 4 işçi başlatmak için:

systemctl enable laravel-queue@1 laravel-queue@2 laravel-queue@3 laravel-queue@4
systemctl start  laravel-queue@1 laravel-queue@2 laravel-queue@3 laravel-queue@4

Bu yaklaşımda Supervisor yok, her işçi kendi systemd servisi olarak izleniyor. Loglar journalctl üzerinden takip edilebilir. Hangi yolu seçeceğiniz ekibinizin alışkanlıklarına bağlı; ancak hangi yolu seçerseniz seçin, temel prensip değişmiyor: queue işçileri FPM havuzundan mantıksal ve kaynak bazında izole olmalı.

Kaynak Planlama: Kaç FPM Süreci, Kaç Queue İşçisi?

İzole mimarinin başarılı olması için, arkasında sağlam bir kapasite hesabı olması gerekir. Kaba bir kural kümesiyle gidelim; diyelim ki elinizde 4 vCPU, 8 GB RAM’li bir NVMe VPS var ve üstünde tek bir Laravel + küçük admin paneli + API koşuyor.

Adım 1: PHP-FPM Havuz RAM Hesabı

Önce ortalama bir PHP sürecinin ne kadar RAM tükettiğine bakın. Örneğin şu komutla FPM süreçlerini incelersiniz:

ps -o pid,cmd,%mem,rss --sort=-%mem | grep "php-fpm: pool" | head -n 10

Diyelim ki session havuzundaki bir PHP süreci ortalama 80 MB, API havuzundaki ise 60 MB kullanıyor. Toplam kullanılabilir RAM’den (OS, MySQL/Redis, kuyruk işçileri vb. düştükten sonra) FPM için 4 GB ayırdığınızı varsayalım:

• Session havuzu: 2 GB → 2GB / 80MB ≈ 25 süreç → pm.max_children = 25
• API havuzu: 2 GB → 2GB / 60MB ≈ 33 süreç → pm.max_children = 30-32 aralığı güvenli olur.

Adım 2: Queue İşçisi RAM Hesabı

Queue işçileri için de benzer bir hesap yapın. Özellikle rapor, PDF üretimi, resim işleme gibi yoğun işlerde bir işçi 300-400 MB’a kadar çıkabiliyor. Diyelim ki job başına ortalama 350 MB ve biz queue tarafına 2 GB RAM ayırmak istiyoruz:

• 2GB / 350MB ≈ 5 işçi → 5 worker makul. Supervisor’da numprocs=5 veya systemd’de 5 unit.
• Üstüne MemoryMax=2G gibi cgroup limiti koyduğunuzda, bu sınır aşılsa bile OOM killer’ın tüm sistemi değil sadece ilgili servisi hedef almasını sağlarsınız.

Bu hesaplar kaba ama sizi doğru bandın içine sokar. Gerçek trafik altında htop, atop, iotop ve uygulama log’ları ile ince ayar yapmanız gerekir. İzleme tarafını yapılandırmak için VPS kaynak kullanımı izleme rehberimiz pratik bir başlangıç noktası sunuyor.

Gerçek Senaryolar: WooCommerce, Laravel API ve Raporlama

Bu mimarinin somut faydasını görmek için üç yaygın senaryoya bakalım.

1. WooCommerce + Promosyon Kampanyası

WooCommerce mağazanızda yoğun indirim dönemi başlıyor. Ön yüzde kullanıcılar sepetlerini dolduruyor, aynı anda kuyrukta fatura PDF’leri ve stok senkronizasyon job’ları çalışıyor. Tek FPM havuzu kullandığınızda şu riskler var:

• Kuyruktan tetiklenen yoğun PHP süreçleri FPM çocuklarını doldurur.
• Session dosyaları kilitlenir, kullanıcılar sepet sayfasında bekler.
• MySQL bağlantı sayısı kontrolsüz artar, veritabanı da zorlanır.

İzole havuz mimarisinde ise:

• Frontend’in bağlı olduğu session_pool için daha korumacı pm.max_children ve request_terminate_timeout değerleri belirlersiniz.
• API ve admin tarafını ayrı havuza alır, gerekiyorsa farklı timeout’lar uygularsınız.
• Queue işçileri asla FPM havuzuna karışmadığı için, kuyrukta patlama olsa da kullanıcılar oturum açmaya devam eder.

2. Laravel API + Mobil Uygulama

Mobil uygulamanız tamamen Laravel API üzerinde çalışıyor. Oturum cookie’si yok, her istek JWT taşıyor. Bu API’yi api_pool havuzuna alarak:

• Session overhead’ini ortadan kaldırırsınız.
• Daha kısa request_terminate_timeout ve daha yüksek pm.max_children ile agresif ölçekleme yapabilirsiniz.
• Arka planda çalışan yoğun queue işlerine rağmen API yanıt sürelerini daha dar bir bantta tutarsınız.

Bu senaryoda, Laravel’in HTTP ve queue katmanlarının birlikte nasıl optimize edileceğini merak ediyorsanız, Laravel prod ortam optimizasyonu yazımızda Octane, Redis ve Horizon ile bir üst seviyeye geçişi de detaylandırdık.

3. Ağır Raporlama ve Batch İşleri

Gece çalışan raporlama job’ları, gün içinde gelen sipariş verilerini özetliyor, PDF çıktıları üretiyor, üçüncü parti servislerle entegrasyon yapıyor. Bu işlerin çalışma saatleri ve SLA’si genellikle farklıdır; birkaç dakika geç çıkması sorun değildir ama kullanıcı oturumu bir saniye bile beklememelidir.

Bu durumda yapmanız gerekenler:

• Rapor job’larını ayrı bir queue ismine (örneğin reports) taşıyın.
• Bu queue için farklı bir systemd unit veya Supervisor program tanımı yapın; daha düşük CPUQuota ve IOWeight verin.
• FPM havuzlarını gün içi ve gece yüklerine göre izleyip, gerekiyorsa cron ya da systemd timer ile gece işçi sayısını arttırıp sabah azaltın.

Loglama, İzlenebilirlik ve Sorun Giderme

Havuzları ve işçi katmanlarını ayırdığınızda, loglama ve izleme de doğal olarak daha net hale gelir. Önerdiğimiz pratikler:

• Havuz bazlı slow log: Her FPM havuzu için ayrı slowlog dosyası tanımlayın. Böylece frontend mi, API mi, admin mi tıkanmış çok net görürsünüz.
• Queue log’larını ayırın: Supervisor veya systemd üzerinden gelen log’ları ayrı dosyalara ya da merkezi log sistemine (Loki, ELK vb.) akıtın.
• Kaynak metrikleri: FPM havuzlarının süreç sayısı, kuyruk uzunlukları, CPU/RAM kullanımını bir panelde toplayın. DCHost VPS altyapısında Prometheus + Grafana ile bu metrikleri toplamış birçok projeye destek veriyoruz.

İyi haber şu ki; izole mimaride bir problem çıktığında “her şey yavaş” yerine “api_pool CPU’ya bindiriyor” veya “queue işçileri MemoryMax’e takılmış” gibi çok daha net cümleler kurabiliyorsunuz. Bu da müdahaleyi hem daha hızlı hem de daha az stresli hale getiriyor.

DCHost Altyapısında İzole Havuz Mimarisi Nasıl Konumlanır?

İzole havuz mimarisi, özellikle NVMe diskli VPS ve dedicated sunucularda en iyi sonucu veriyor. Çünkü FPM havuzları, veritabanı ve queue işçileri aynı fiziksel kaynakları paylaşıyor ve disk I/O performansı burada kritik hale geliyor. DCHost olarak sağladığımız VPS ve fiziksel sunucu altyapılarında, müşterilerimizin büyük kısmı:

• En az iki PHP-FPM havuzu (session + API),
• Ayrı cgroup’larda çalışan queue işçileri,
• Redis tabanlı session + cache katmanı,
• Ve çoğu zaman ayrı bir veritabanı sunucusu

ile bu modeli uyguluyor. Veritabanı ve uygulama sunucusunu ayırmanın ne zaman mantıklı hale geldiğini merak ediyorsanız, veritabanı sunucusunu uygulamadan ayırma rehberimiz de güzel tamamlayıcı olur.

Eğer şu an tek PHP-FPM havuzu, tek Supervisor süreci ve karışık job’larla ilerliyorsanız; önce küçükten başlayın: iki FPM havuzu + limitli queue servisi. Ardından trafik ve metrikleri izleyip, gerektikçe ek havuz veya ek queue grubu tanımlayın. Bu geçişi DCHost üzerinde yeni bir VPS veya dedicated sunucu ile yeşil alan (greenfield) olarak da planlayabilirsiniz; eski mimariyi klonlayıp, bu yazıdaki adımlarla adım adım sertleştirmeniz mümkün.

Özet ve Sonraki Adımlar

PHP dünyasında performans ve stabilite sorunlarının önemli bir kısmı, hatalı koddan çok yanlış kaynak paylaşımından kaynaklanıyor. Session yöneten kısa ömürlü HTTP istekleri ile ağır queue job’larını aynı havuzda koşturduğunuzda, en ufak bir dalgalanmada tüm sistemin dengesinin bozulması kaçınılmaz. Bu yazıda anlattığımız izole havuz mimarisiyle:

• PHP-FPM tarafında session ve API isteklerini ayrı havuzlarda tutarak concurrency ve timeout’ları ince ayar yapabildik.
• Queue işçilerini Supervisor ve/veya systemd ile bağımsız bir katmana alıp, CPU ve RAM limitleriyle FPM’i koruma altına aldık.
• Kaynak planlama, loglama ve izleme sayesinde sorun çıktığında kök sebebe çok daha hızlı ulaşabileceğimizi gösterdik.

Şimdi sırada kendi projeniz var. Mevcut PHP-FPM ve queue mimarinizi gözden geçirip, hangi havuzların ayrılması gerektiğini bir listeye dökebilirsiniz. DCHost altyapısında yeni bir NVMe VPS veya dedicated sunucu planlıyorsanız, kapasite ve mimari tasarımı beraber yapalım; PHP-FPM havuz ayarlarından queue işçilerine kadar uçtan uca bir yapı kurmak bizim günlük işimiz. İsterseniz önce kuyruk yönetimi ve session/cache seçimi yazılarımızı da okuyup büyük resmi tamamlayabilirsiniz. Bundan sonrası, birkaç iyi planlanmış havuz dosyası ve doğru sistemd ayarlarıyla oldukça keyifli bir yolculuk.