Eşzamanlı Kullanıcı Kapasitesi Hesaplama

"Bu sunucu kaç kişi kaldırır?" sorusuna satış sayfalarında verilen "aylık 100.000 ziyaretçi" tarzı cevaplar neredeyse hiçbir işe yaramaz. Çünkü aylık toplam ziyaretçi sayısı ile sunucunuzun aynı anda kaç isteği işleyebildiği arasında doğrudan bir bağ yoktur. Ayda 100.000 ziyaretçinin düzgün dağıldığı bir blog ile aynı 100.000 ziyaretçiyi kampanya gecesinin iki saatinde alan bir e-ticaret sitesi tamamen farklı sunuculara ihtiyaç duyar.

Eşzamanlı kullanıcı kapasitesi hesaplama, işte bu boşluğu kapatan hesaptır: elinizdeki RAM, CPU ve ortalama yanıt süresinden yola çıkarak sunucunuzun aynı anda kaç aktif kullanıcıya hizmet verebileceğini bulursunuz. Bu rehberde önce "eşzamanlı kullanıcı" teriminin gerçekte neyi ölçtüğünü netleştireceğim, sonra Little yasası ile ziyaretçi sayısını istek/saniyeye çevireceğiz, ardından PHP-FPM havuzunu ve veritabanı bağlantı limitini bu sayıya göre boyutlandıracağız. Sonunda elinizde tahmin değil, hesaplanmış bir kapasite rakamı olacak.

"Eşzamanlı Kullanıcı" Aslında Ne Demek#

Terim üç farklı anlamda kullanıldığı için kafa karışıklığı buradan başlar. Birincisi sitede açık olan kullanıcı: sayfayı okuyan ama hiçbir istek göndermeyen ziyaretçi. Google Analytics'in "şu an aktif" sayısı budur ve sunucunuza sıfır yük bindirir. İkincisi aktif oturum: son birkaç dakika içinde en az bir istek göndermiş kullanıcı. Üçüncüsü ve teknik olarak asıl önemlisi eşzamanlı istek: şu anda sunucunuzun işlemekte olduğu HTTP isteği sayısı.

Aradaki fark devasadır. 500 kişi sitenizde açık sekmede duruyor olabilir ama bunların yalnızca 5-10 tanesi aynı milisaniyede istek gönderiyordur. Çünkü bir kullanıcı sayfayı yükledikten sonra ortalama 30-60 saniye okur, sonra bir bağlantıya tıklar. Bu okuma süresine "think time" denir ve kapasite hesabının kalbidir.

Sunucu kapasitesi planlarken hesap yapmanız gereken birim eşzamanlı istek ve RPS'dir. "Kaç kullanıcı" sorusunu bu ikisine çevirmeden hiçbir doğru cevaba ulaşamazsınız.

Little Yasası ile Kullanıcıdan RPS'ye Geçmek#

Kuyruk teorisinden gelen Little yasası bu dönüşümün formülüdür ve akılda tutulacak kadar basittir:

Eşzamanlı istek = İstek/saniye  ×  Ortalama yanıt süresi (saniye)

Yani sunucunuz saniyede 200 istek işliyorsa ve her istek ortalama 0.25 saniye sürüyorsa, herhangi bir anda içeride 200 × 0.25 = 50 istek işlenmektedir. Bu, PHP-FPM'de aynı anda meşgul olması gereken işçi (worker) sayısıdır.

Aynı formülü ters çevirip kullanıcıdan yola çıkabilirsiniz. Bir kullanıcının sayfa görüntülemeleri arasında ortalama 40 saniye beklediğini ve her sayfa görüntülemesinin 8 istek (HTML + CSS + JS + görseller) ürettiğini varsayalım:

Kullanıcı başına RPS = Sayfa başına istek / Ortalama bekleme süresi
                     = 8 / 40 = 0.2 istek/saniye

1000 eşzamanlı kullanıcı → 1000 × 0.2 = 200 istek/saniye

Ama burada kritik bir ayrım var: bu 200 isteğin çoğu statik dosyadır (CSS, JS, görsel) ve Nginx bunları neredeyse bedavaya servis eder. Asıl pahalı olan dinamik istektir. 8 istekten yalnızca 1'i PHP'ye gidiyorsa dinamik yük şudur:

Dinamik RPS = 1000 × (1 / 40) = 25 istek/saniye
Gereken PHP işçisi = 25 × 0.25 (ortalama PHP süresi) ≈ 7 işçi

Yani 1000 eşzamanlı okuyucu, iyi optimize edilmiş bir sitede yalnızca 7 PHP işçisi meşgul eder. Aynı hesabı ortalama PHP süresi 0.25 yerine 1.2 saniye olan yavaş bir sitede yaparsanız 30 işçi gerekir ve bu, RAM ihtiyacınızı dörde katlar. Yanıt süresini düşürmenin kapasite üzerindeki etkisi doğrudan ve doğrusaldır.

Gerçek Verinizden Zirve Eşzamanlılığı Çıkarmak#

Formüller ancak doğru girdilerle işe yarar. Bu girdileri tahmin etmek yerine kendi loglarınızdan çıkarın. Nginx erişim logundan en yoğun dakikanın istek sayısını bulmak için:

# Saniye bazında en yoğun 5 anı bul (log formatı: [10/Aug/2026:14:22:31 +0300])
awk -F'[][]' '{print $2}' /var/log/nginx/access.log \
  | cut -d' ' -f1 | sort | uniq -c | sort -rn | head -5

Dinamik ve statik ayrımını görmek için PHP'ye giden istekleri ayrı sayın:

# Toplam istek
grep -c "" /var/log/nginx/access.log
# Sadece PHP istekleri
grep -c '\.php' /var/log/nginx/access.log

Ortalama yanıt süresini almak içinse log formatınıza $request_time eklemeniz gerekir:

# /etc/nginx/nginx.conf içinde http bloğuna
log_format zamanli '$remote_addr - $request "$request" $status '
                   '$body_bytes_sent rt=$request_time uct="$upstream_connect_time" '
                   'urt="$upstream_response_time"';

access_log /var/log/nginx/access.log zamanli;

Bu satırı ekleyip Nginx'i yeniden yükledikten sonra ortalama ve zirve değerleri kolayca çıkarırsınız:

# Ortalama request_time
awk '{for(i=1;i<=NF;i++) if($i ~ /^rt=/){split($i,a,"="); s+=a[2]; n++}} END {print "ortalama:", s/n}' /var/log/nginx/access.log

# En yavaş 10 istek
awk '{for(i=1;i<=NF;i++) if($i ~ /^rt=/){split($i,a,"="); print a[2], $7}}' /var/log/nginx/access.log | sort -rn | head -10

Elinizde ortalama yanıt süresi ve zirve RPS varsa artık gerçek eşzamanlılığınızı biliyorsunuz demektir. Bu sayıyı doğrulamanın en iyi yolu, hesapladığınız değeri ApacheBench ile yük testi ya da daha gerçekçi bir senaryo için Siege ve Locust ile yük testi yaparak sınamaktır. Hesap ile ölçüm birbirini tutuyorsa modeliniz doğrudur.

PHP-FPM Havuzunu RAM'e Göre Boyutlandırmak#

Kapasite hesabının en somut çıktısı pm.max_children değeridir. Bu değer, PHP'nin aynı anda kaç isteği işleyebileceğini belirler ve yanlış ayarlanması sunucu çökmelerinin bir numaralı sebebidir. Formül şudur:

pm.max_children = (Kullanılabilir RAM) / (Bir PHP sürecinin ortalama RAM'i)

Önce bir PHP sürecinin gerçekte ne kadar RAM tükettiğini ölçün — varsayım yapmayın:

# PHP-FPM süreçlerinin ortalama RSS değeri (MB cinsinden)
ps --no-headers -o rss,cmd -C php-fpm8.2 \
  | awk '{s+=$1; n++} END {print "ortalama:", s/n/1024, "MB — süreç sayısı:", n}'

WordPress gibi eklenti yüklü bir kurulumda tipik değer 60-120 MB arasındadır. 8 GB RAM'li bir sunucuda işletim sistemi, MySQL ve Nginx için 3 GB ayırdığınızı varsayalım:

Kullanılabilir RAM = 8192 MB - 3072 MB = 5120 MB
Süreç başına RAM   = 90 MB
pm.max_children    = 5120 / 90 ≈ 56

Yapılandırmayı buna göre yazın:

; /etc/php/8.2/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 56
pm.start_servers = 14
pm.min_spare_servers = 8
pm.max_spare_servers = 24
pm.max_requests = 500          ; bellek sızıntısına karşı süreci yenile
pm.status_path = /status       ; doygunluk izlemek için

pm.max_requests satırını atlamayın: uzun süre yaşayan PHP süreçleri eklenti kaynaklı bellek sızıntılarıyla şişer ve zamanla max_children hesabınızı geçersiz kılar. pm.status_path ise havuzun ne kadar dolu olduğunu canlı görmenizi sağlar:

curl -s http://127.0.0.1/status?full | grep -E 'active processes|listen queue|max children reached'

Çıktıdaki max children reached sayacı sıfırdan büyükse havuzunuz zirve anında dolmuş ve istekler kuyruğa girmiş demektir; ya max_children değerini artırmanız ya da RAM eklemeniz gerekir. listen queue sıfırdan büyükse aynı sorunun anlık halini görüyorsunuz.

Web Sunucusu ve Veritabanı Katmanının Limitleri#

PHP havuzunu doğru boyutlandırmak tek başına yetmez; zincirin her halkası aynı kapasiteye ayarlanmalıdır. Nginx tarafında iki değer önemlidir:

# /etc/nginx/nginx.conf
worker_processes auto;              # CPU çekirdeği kadar
events {
    worker_connections 4096;        # işçi başına eşzamanlı bağlantı
    multi_accept on;
}
# Teorik tavan: worker_processes × worker_connections
# 4 çekirdek × 4096 = 16.384 eşzamanlı bağlantı

Bu sayı büyük görünür ama unutmayın: her ziyaretçi keep-alive sayesinde birden fazla bağlantı tutar ve statik dosyalar da bu havuzu kullanır. Ayrıca işletim sistemi tarafında açık dosya tanıtıcısı (file descriptor) limitini yükseltmezseniz Nginx bu sayıya asla ulaşamaz:

# Mevcut limit
ulimit -n
# Kalıcı artırım: /etc/security/limits.conf
# nginx soft nofile 65535
# nginx hard nofile 65535

Veritabanı katmanı genellikle asıl darboğazdır ve hesabı basittir: her PHP süreci en az bir MySQL bağlantısı açar, dolayısıyla max_connections değeri pm.max_children değerinden büyük olmalıdır.

; /etc/mysql/mysql.conf.d/mysqld.cnf
max_connections = 100          ; pm.max_children (56) + yönetim payı
innodb_buffer_pool_size = 2G   ; sık okunan veriyi RAM'de tut

Bu üç katmanı birlikte planlamanın en pratik yolu bir tablo çıkarmaktır. Tipik bir WordPress/e-ticaret kurulumu için başlangıç değerleri:

Bu değerler ortalama 90 MB'lık PHP süreçleri ve 0.25 saniyelik yanıt süresi varsayımına dayanır; kendi ölçümünüzle mutlaka düzeltin. Kaynakları kendiniz yönetmek istiyorsanız VDS paketlerinde tüm bu değerleri root erişimiyle serbestçe ayarlayabilirsiniz.

Önbelleğin Kapasiteye Etkisi: En Ucuz Kaynak Artışı#

Kapasite denklemini değiştirmenin en ucuz yolu daha güçlü sunucu almak değil, isteklerin PHP'ye hiç ulaşmamasını sağlamaktır. Tam sayfa önbelleği devredeyken bir istek Nginx tarafından diskteki hazır HTML'den servis edilir ve PHP ile MySQL hiç çalışmaz. Aradaki fark iki büyüklük mertebesidir:

Yani %90 önbellek isabet oranına ulaşmak, sunucunuzun kapasitesini kabaca on katına çıkarır. Kurulum için Nginx FastCGI cache yapılandırma yazısındaki adımları izleyebilir, LiteSpeed kullanıyorsanız LiteSpeed Cache eklentisiyle aynı sonucu birkaç tıkla alabilirsiniz. Veritabanı sorgularını tekrar tekrar çalıştırmamak için ise Memcached ya da Redis tabanlı bir nesne önbelleği ekleyin.

Önemli uyarı: giriş yapmış kullanıcılar (sepet, panel, üyelik sayfaları) genellikle önbelleklenemez. E-ticaret sitelerinde kapasite hesabını önbelleklenemeyen trafik üzerinden yapın; kampanya gününde herkesin sepetinde ürün olduğunu ve tam sayfa önbelleğinin devre dışı kaldığını unutmayın.

Sık Yapılan Hesap Hataları#

Aylık ziyaretçiden kapasite çıkarmak. Ayda 300.000 sayfa görüntülemesi, düzgün dağılırsa saniyede 0.11 istek demektir; ama trafiğin %40'ı üç saatte gelirse aynı site saniyede 11 isteğe çıkar. Her zaman zirve saati temel alın, ortalamayı değil.

pm.max_children değerini yüksek tutmanın zararsız olduğunu sanmak. Bu, kapasite hesabında gördüğüm en pahalı hatadır. 8 GB RAM'li sunucuda pm.max_children = 200 yazarsanız zirve anında 200 süreç × 90 MB = 18 GB RAM talep edilir; sunucu takasa (swap) düşer, disk kilitlenir ve site tamamen erişilmez olur. Havuzu doldurmak yavaşlamaya, taşırmak çökmeye yol açar; ikincisi çok daha kötüdür.

CPU'yu hesaba katmamak. RAM hesabınız 60 işçiye izin verse bile, 2 çekirdekli bir sunucuda 60 PHP süreci aynı anda gerçekten çalışamaz; sadece sıraya girerler ve yanıt süresi uzar. Pratik kural: CPU çekirdeği başına 4-6 aktif PHP işçisi. Hesabınızın RAM tavanı ile CPU tavanının küçük olanını alın.

Statik ve dinamik trafiği ayırmamak. Toplam RPS üzerinden PHP havuzu boyutlandırmak, ihtiyacınızın 5-10 katı işçi tanımlamanıza yol açar. Logdan .php oranını çıkarıp yalnızca o kısmı hesaba katın.

Üçüncü parti servisleri unutmak. Ödeme sağlayıcısına, kargo API'sine ya da harici bir e-posta servisine yapılan senkron çağrılar PHP sürecini bekletir. 2 saniye bekleyen bir API çağrısı, o işçiyi 2 saniye boyunca başka hiçbir isteğe hizmet edemez hale getirir; kapasiteniz o oranda düşer. Bu tür çağrıları mümkünse kuyruğa alın.

Sıkça Sorulan Sorular#

Sunucum kaç eşzamanlı kullanıcı kaldırır, kısa bir cevap var mı#

Kısa cevap yok ama hızlı bir yaklaşım var: kullanılabilir RAM'i bir PHP sürecinin ortalama RAM'ine bölün, çıkan sayıyı ortalama yanıt sürenize bölün, sonucu sayfa başına düşen bekleme süresiyle çarpın. 8 GB RAM, 90 MB süreç ve 0.25 saniye yanıt süresiyle kabaca 56 eşzamanlı PHP isteği, bu da 40 saniye okuma süresi varsayımıyla birkaç bin eşzamanlı okuyucu eder. Ama bu rakam önbellek isabet oranınıza göre kolayca on kat değişir; kesin cevabı ancak kendi sitenizde yük testi verir.

Eşzamanlı kullanıcı ile istek/saniye arasındaki fark nedir#

Eşzamanlı kullanıcı sitenizde bulunan kişi sayısıdır, istek/saniye ise sunucunuza gelen HTTP isteklerinin hızıdır. İkisi arasındaki köprü kullanıcının bekleme süresidir: 40 saniyede bir sayfa açan 1000 kullanıcı, saniyede 25 sayfa isteği üretir. Sunucu planlaması her zaman istek/saniye ve eşzamanlı istek üzerinden yapılır; kullanıcı sayısı yalnızca bir girdidir.

PHP-FPM max_children değerini nasıl belirlerim#

Önce ps komutuyla mevcut PHP süreçlerinizin ortalama bellek kullanımını ölçün. Sonra toplam RAM'den işletim sistemi, veritabanı ve web sunucusu için ayırmanız gereken payı düşün. Kalan miktarı süreç başına belleğe bölün. Çıkan sayı üst sınırınızdır; CPU çekirdeği başına 4-6 işçi kuralıyla karşılaştırıp küçük olanı seçin. Ayarladıktan sonra pm.status_path üzerinden "max children reached" sayacını takip edin.

Yük testi yapmadan kapasite hesabı güvenilir mi#

Hesap size doğru büyüklük mertebesini verir ama gerçek davranışı vermez. Formüller ortalama yanıt süresi ve ortalama bellek kullanımı üzerine kuruludur; oysa gerçek trafikte bazı sayfalar diğerlerinden on kat ağırdır ve yük arttıkça yanıt süresi doğrusal değil, üstel biçimde artar. Hesabı planlama için, yük testini doğrulama için kullanın; ikisi uyuşmuyorsa kaçırdığınız bir darboğaz vardır.

Trafik arttığında dikey mi yoksa yatay mı büyümeliyim#

Önce dikey (daha fazla RAM ve CPU) büyümek neredeyse her zaman daha ucuz ve daha basittir; tek sunucuda kalmak oturum yönetimi, dosya paylaşımı ve veritabanı çoğaltma karmaşasından kurtarır. Tek sunucunun makul sınırlarını zorlamaya başladığınızda ya da kesintisizlik ihtiyacı doğduğunda yatay büyümeye (birden fazla uygulama sunucusu ve önünde yük dengeleyici) geçin. Yatay büyümeden önce mutlaka önbellek katmanını kurun; çoğu site aslında sunucuya değil önbelleğe ihtiyaç duyar.

Önbellek isabet oranımı nasıl ölçerim#

Nginx FastCGI cache kullanıyorsanız log formatınıza $upstream_cache_status değişkenini ekleyin; ardından logda HIT, MISS ve BYPASS satırlarını sayarak oranı çıkarın. LiteSpeed tarafında yanıt başlıklarındaki x-litespeed-cache değerine bakabilirsiniz. Hedefiniz giriş yapmamış ziyaretçiler için %85 üzerinde isabet oranıdır; bunun altındaysanız önbellek kurallarınız gereğinden fazla sayfayı dışarıda bırakıyordur.

Kapanış#

Kapasite planlaması tahmin işi değil, birkaç ölçüm ve bir bölme işlemidir. Aklınızda kalması gereken dört şey: kapasiteyi aylık ziyaretçiden değil zirve saatteki istek/saniyeden hesaplayın, pm.max_children değerini gerçek RAM ölçümüyle belirleyip CPU tavanıyla karşılaştırın, PHP havuzu ile veritabanı bağlantı limitini birlikte planlayın ve en ucuz kapasite artışının önbellek olduğunu unutmayın. Hesabı yaptıktan sonra mutlaka bir yük testiyle doğrulayın.

Hesap sonucunda mevcut paketinizin yetmediğini görürseniz, kaynakları ihtiyacınıza göre seçebileceğiniz VDS ve bulut sunucu paketlerimiz esnek bir başlangıç noktasıdır; yoğun trafikli projeler için kaynakların hiç paylaşılmadığı dedicated sunucu seçenekleri vardır. PHP-FPM havuzu, MySQL ayarları ve önbellek katmanını sizin yerinize kurmamızı isterseniz sunucu yönetimi hizmetimiz tam olarak bu işi üstlenir. Basit bir trafik/bant genişliği tahmini için bant genişliği hesaplayıcı aracımızı da kullanabilirsiniz.