Kaç Ziyaretçi İçin Hangi Hosting Paketi Yeterli?

"Günde 5.000 ziyaretçim var, hangi hosting paketi yeterli?" sorusunun internetteki cevaplarının neredeyse tamamı aynı kalıptadır: "1.000–10.000 ziyaretçi için başlangıç paketi, 10.000–50.000 için profesyonel paket yeterlidir." Bu aralıklar hiçbir hesaba dayanmaz. Aynı 5.000 ziyaretçi, tam sayfa önbellekli bir blogda saatte birkaç PHP isteği üretirken; sepet, üyelik ve filtreli arama içeren bir WooCommerce mağazasında aynı sayının otuz katı kadar dinamik istek üretir. Kaç ziyaretçi için hangi hosting paketi sorusunun gerçek cevabı ziyaretçi sayısında değil, o ziyaretçilerin sunucuda aynı anda kaç PHP süreci meşgul ettiğinde saklıdır.

Bu yazıda ziyaretçi sayısını adım adım eşzamanlı isteğe, oradan da gereken PHP worker sayısına çeviren bir hesap kuruyoruz. Yıllardır gördüğüm en yaygın hata, insanların "aylık trafik" (bant genişliği) rakamına bakıp karar vermesidir — oysa paylaşımlı hostingte sizi durduran şey neredeyse hiçbir zaman bant genişliği olmaz, eşzamanlı süreç (entry process) limiti olur. Aşağıdaki adımları kendi sitenizin access log'u ve cPanel istatistikleriyle uygulayarak, tahmin yerine ölçüme dayalı bir paket kararı verebilirsiniz.

Ziyaretçi Sayısı Neden Tek Başına Anlamsız#

Bir hosting hesabının kapasitesini belirleyen dört bağımsız kaynak vardır ve ziyaretçi sayısı bunların hiçbirini doğrudan ölçmez: CPU zamanı, bellek, disk G/Ç (IOPS) ve eşzamanlı süreç sayısı. Aynı günlük ziyaretçiye sahip iki site bu dördünde tamamen farklı yerlerde durabilir.

Somut bir karşılaştırma: statik olarak önbelleğe alınmış bir kurumsal tanıtım sitesinde bir sayfa görüntüleme, sunucuya bir HTML dosyası okutur ve yanıt 5–15 ms içinde biter. PHP hiç çalışmaz. Aynı sayfa görüntüleme, önbelleksiz bir WooCommerce ürün listesinde 15–20 veritabanı sorgusu, eklenti başına birkaç option okuması ve 400–900 ms'lik bir PHP çalışma süresi anlamına gelir. İkinci durumda sunucu, birincisine göre yaklaşık elli kat daha uzun süre meşgul kalır. Ziyaretçi sayısı ikisinde de aynıdır.

Dolayısıyla doğru soru şudur: sitem yoğun anında sunucuda aynı anda kaç dinamik istek işletiyor? Bu sayı, hosting paketinin ilan ettiği "sınırsız trafik" ifadesinden çok daha belirleyicidir. Sınırsız ifadesinin arkasında ne olduğunu ayrıca sınırsız hosting gerçekten sınırsız mı yazısında ele aldık.

Günlük Ziyaretçiyi Eşzamanlı İsteğe Çevirme Formülü#

Eşzamanlı istek sayısı, kuyruk teorisindeki Little Yasası ile hesaplanır: sistemde aynı anda bulunan iş sayısı, geliş hızı ile ortalama işlem süresinin çarpımıdır.

Eşzamanlı PHP isteği (L) = Zirve saniyedeki dinamik istek (λ) × Ortalama PHP süresi (W)

Günlük ziyaretçiden bu iki değere şu dört adımda ineriz:

1. Sayfa görüntülemeye çevir. Günlük ziyaretçi × oturum başına sayfa. Türkiye'de içerik sitelerinde bu oran tipik olarak 1,5–3 arasındadır; e-ticarette 4–8'e çıkar. Analytics'inizde "Oturum başına sayfa" metriğine bakın, tahmin etmeyin.
2. Zirve saate indir. Günlük trafiğin tamamı 24 saate eşit dağılmaz. Türkiye hedefli bir sitede zirve saat genelde 20:00–23:00 arasıdır ve günlük trafiğin %10–15'i o tek saatte gerçekleşir. Güvenli tarafta kalmak için %15 alın.
3. Saniyeye böl ve dalgalanma payı ekle. Saatlik isteği 3600'e bölmek size ortalama hızı verir. Gerçek trafik düz değildir; bir sosyal medya paylaşımı veya arama motoru dalgası anlık hızı ortalamanın 3–5 katına çıkarır. Bu çarpanı burst faktörü olarak ekleyin.
4. Dinamik olanı ayır. Statik dosyalar (CSS, JS, görsel, font) PHP worker tüketmez; web sunucusu bunları doğrudan diskten verir. Önbelleksiz WordPress'te sayfa görüntülemelerin neredeyse tamamı dinamiktir; tam sayfa önbellek varsa dinamik oran %2–10'a düşer.

Bir örnek üzerinden yürütelim. Günde 5.000 ziyaretçi, oturum başına 2,4 sayfa, tam sayfa önbelleksiz bir WordPress sitesi:

Sayfa görüntüleme       = 5.000 × 2,4        = 12.000 / gün
Zirve saatteki görüntüleme = 12.000 × 0,15   = 1.800 / saat
Ortalama hız (λ)        = 1.800 / 3600       = 0,5 istek/sn
Burst faktörü ×4        = 0,5 × 4            = 2,0 istek/sn
Ortalama PHP süresi (W) = 0,6 sn (ölçülecek)
Eşzamanlı PHP (L)       = 2,0 × 0,6          = 1,2 worker

Sonuç 1,2. Yani bu site zirve anında sunucunun ortalama 1–2 PHP sürecini meşgul eder. İyi bir paylaşımlı hosting hesabında tipik eşzamanlı süreç limiti 20 civarındadır; bu site limitin onda birini bile kullanmaz. "Günde 5.000 ziyaretçi paylaşımlı hosting için çok" iddiası, ölçüldüğünde çoğunlukla yanlıştır.

Şimdi aynı hesabı ağır bir mağaza için tekrarlayalım: 5.000 ziyaretçi, oturum başına 6 sayfa, PHP süresi 1,1 sn, ürün listeleri ve sepet önbelleklenemez.

Sayfa görüntüleme       = 5.000 × 6          = 30.000 / gün
Zirve saat (%15)        = 4.500 / saat
λ                       = 1,25 istek/sn
Burst ×4                = 5,0 istek/sn
L                       = 5,0 × 1,1          = 5,5 worker

Aynı ziyaretçi sayısı, dört kattan fazla eşzamanlı süreç demek. Kampanya günü burst faktörü 8'e çıkarsa 11 worker'a fırlar ve 20'lik limitin yarısını tek başına yer. Bu, "paketim yetiyor ama kampanyada 508 hatası alıyorum" tablosunun matematiğidir.

Kendi Sitenizin Dört Sayısını Ölçme#

Formülde tahmin edilecek hiçbir şey yok; dördü de ölçülebilir. Sırayla:

1. Sayfa görüntüleme ve zirve saat. cPanel'de Ölçümler bölümündeki ziyaretçi raporlarından saatlik dağılımı görebilirsiniz; bu ekranların nasıl okunacağını cPanel ziyaretçi istatistikleri yazısında anlattık. Daha kesin sonuç için ham access log'u sayın:

awk '{print $4}' ~/access-logs/siteniz.com \
  | cut -d: -f2 | sort | uniq -c | sort -rn | head -5

Çıktı şuna benzer:

  4187 21
  3902 20
  3610 22
  2988 14
  2455 13

Buradaki 4187, o gün saat 21'de gelen toplam istek sayısıdır (statik dosyalar dahil).

2. Dinamik istek oranı. Aynı log'dan sadece PHP'ye giden istekleri ayıklayın:

grep -vE '\.(css|js|jpe?g|png|gif|webp|svg|woff2?|ico|map)(\?|" )' \
  ~/access-logs/siteniz.com | wc -l

Toplam isteğe bölünce dinamik oranınızı bulursunuz. Önbelleği doğru kurulmuş bir WordPress'te bu oran %5–15 civarında olmalıdır. %60'ın üzerindeyse önbellek ya yok ya da çalışmıyor demektir.

3. Ortalama PHP süresi (W). En sağlam kaynak sunucunun kendi kaydıdır. Nginx tarafında log formatına $upstream_response_time ekleyip ortalamasını alabilirsiniz:

log_format timed '$remote_addr "$request" $status '
                 'rt=$request_time urt=$upstream_response_time';
access_log /var/log/nginx/site.access.log timed;

Log birikmeye başladıktan sonra son 10.000 isteğin ortalamasını alın:

tail -n 10000 /var/log/nginx/site.access.log \
  | grep -o 'urt=[0-9.]*' | cut -d= -f2 \
  | awk '{s+=$1; n++} END {printf "ortalama %.3f sn / %d istek\n", s/n, n}'

Paylaşımlı hostingte log formatına erişemiyorsanız kaba bir yaklaşım olarak sunucu yanıt süresini (TTFB) kullanabilirsiniz. TTFB'nin neyi kapsadığı ve neyi kapsamadığı konusunda TTFB nedir nasıl düşürülür yazısı ayrıntılı.

4. Burst faktörü. En yoğun dakikadaki istek sayısını 60'a bölüp, saatlik ortalama hıza oranlayın:

awk '{print substr($4,2,17)}' ~/access-logs/siteniz.com \
  | sort | uniq -c | sort -rn | head -3

Bu size dakika bazında zirveyi verir. Çıkan oran genelde 3 ile 6 arasındadır; haber/kampanya siteleri 10'u geçebilir.

Önbelleğin Hesabı Nasıl Değiştirdiği#

Tam sayfa önbellek, formüldeki iki değişkeni birden küçültür: dinamik istek oranını ve ortalama PHP süresini. Etkisi çarpımsal olduğu için sonuç dramatiktir.

Önbelleksiz bir sitede 30.000 sayfa görüntülemenin 30.000'i PHP'ye gider. LiteSpeed Cache veya benzeri bir tam sayfa önbelleğiyle, aynı içerik için ilk istek PHP çalıştırır, sonraki isteklere hazır HTML sunulur. Önbellek isabet oranı %92 ise PHP'ye giden istek 2.400'e düşer — on ikide bir. Yukarıdaki mağaza örneğindeki 5,5 worker, sepet ve ödeme sayfaları hariç tutulduğunda 1'in altına iner.

Ancak burada kritik bir ayrım var: her sayfa önbelleklenemez. Oturum açmış kullanıcı, dolu sepet, ödeme adımı, hesabım sayfası, canlı stok bilgisi ve arama sonuçları kullanıcıya özeldir. Bir e-ticaret sitesinde trafiğin %70'i önbelleklenebilir kategori/ürün sayfası olsa bile, kalan %30 tamamen PHP'ye düşer ve bunlar aynı zamanda en ağır sayfalardır. Bu yüzden mağazalarda önbellek, blogdaki kadar kurtarıcı olmaz.

Nesne önbelleği (Redis/Memcached) ise ayrı bir kaldıraçtır: sayfayı hazır sunmaz ama veritabanı sorgu sayısını düşürerek W değerini kısaltır. Tipik olarak ağır bir WooCommerce sayfasında 900 ms'lik süreyi 500–600 ms'ye indirir. Formülde W yarıya inerse gereken worker sayısı da yarıya iner.

Paylaşımlı Hostingte Sizi Durduran Şey Trafik Değil, EP Limiti#

Paylaşımlı hosting hesaplarında sınırlar CloudLinux LVE katmanıyla uygulanır ve bunlar bant genişliği değil, anlık kaynak sınırlarıdır:

Buradaki EP, formülde hesapladığımız L değerinin doğrudan karşılığıdır. Hesabınızın EP limiti 20 ise ve zirvede 22 eşzamanlı PHP isteğiniz varsa, 21. ve 22. ziyaretçi 508 hatası görür. Sitenin geri kalanı hâlâ çalışıyordur — bu yüzden "bende açılıyor" yanılgısı sık yaşanır. Hatanın okuma biçimi ve geçici çözümleri için 508 Resource Limit Is Reached hatası yazısına, limitlerin genel mantığı için paylaşımlı hosting kaynak limitleri yazısına bakın.

cPanel'de Kaynak Kullanımı ekranından hangi limitin kaç kez tetiklendiğini görebilirsiniz. Burada okumanız gereken şey hangi limitin dolduğudur:

• Sürekli EP doluyorsa: eşzamanlılık sorunu → önbellek veya daha yüksek EP'li paket/VDS.
• Sürekli SPEED doluyorsa: kod/sorgu ağır → optimizasyon veya daha fazla CPU.
• Sürekli PMEM doluyorsa: tek istek çok bellek yiyor → eklenti temizliği, memory_limit ayarının gözden geçirilmesi.
• Sürekli IO doluyorsa: log/yedek/arama sorguları diski dövüyor.

Dördü aynı anda dolmuyorsa "paket yetmiyor" demek erken bir teşhistir.

Site Tipine Göre Kapasite Tablosu#

Aşağıdaki tablo yukarıdaki formülün farklı site tipleri için çalıştırılmış hâlidir. Sayılar kesin eşik değil, kendi ölçümünüzü yerleştireceğiniz referans noktalarıdır.

Tablodaki "zirve eşzamanlı PHP" sütunu 15'i geçmeye başladığında paylaşımlı hosting artık doğru araç değildir — çünkü orada 20'lik EP limitine tek kampanya duyurusuyla çarparsınız. Paket seçim kriterlerinin tamamı için hangi hosting paketini seçmeliyim yazısı bu hesabın etrafındaki diğer başlıkları (disk, e-posta, panel, yedek) tamamlıyor.

VDS'e Ne Zaman Geçmeniz Gerekir ve Kaç Çekirdek RAM Gerekir#

VDS'e geçiş kararı için üç sinyalden en az ikisi gerekir: EP limiti düzenli olarak doluyor, ortalama PHP süresi optimize edilmiş hâlde bile 500 ms'nin üstünde kalıyor, ya da mimarî bir ihtiyaç var (kendi PHP eklentiniz, Redis, Node.js servisi, farklı bir web sunucusu, özel cron sıklığı).

VDS'te limit artık EP değil, PHP-FPM havuzunuzdur ve bu sefer sayıyı siz belirlersiniz:

; /etc/php/8.3/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 24
pm.start_servers = 6
pm.min_spare_servers = 4
pm.max_spare_servers = 10
pm.max_requests = 500

pm.max_children değeri şu şekilde hesaplanır:

max_children = (Toplam RAM − İşletim sistemi − MySQL − Redis) / Ortalama PHP süreç belleği

Bir PHP süreç belleğini ölçmek için:

ps --no-headers -o rss,cmd -C php-fpm8.3 \
  | awk '{s+=$1; n++} END {printf "ortalama %.0f MB / %d süreç\n", s/n/1024, n}'

Tipik bir WordPress kurulumunda süreç başına 60–110 MB görürsünüz. 8 GB RAM'li bir sunucuda 1 GB işletim sistemi, 2 GB MySQL, 512 MB Redis ayırırsanız PHP'ye ~4,5 GB kalır; 90 MB'lık süreçlerle bu yaklaşık 50 worker eder. Bu, yukarıdaki tablodaki en ağır senaryonun bile iki katıdır.

vCPU tarafında pratik kural: eşzamanlı worker sayısı vCPU sayısının 4–6 katını geçmemelidir. 20 eşzamanlı PHP isteği bekliyorsanız 4 vCPU makul bir başlangıçtır; daha fazla worker tanımlamak CPU'yu bağlam değiştirmeye boğar ve toplam gecikmeyi artırır. Havuz parametrelerinin ayrıntısı için PHP-FPM pool ayarları yazısına bakabilirsiniz.

Bant genişliği tarafını da unutmayın: 30.000 sayfa görüntüleme × ortalama 1,8 MB sayfa ağırlığı ≈ 54 GB/gün eder. Sayfa ağırlığınızı düşürmeden trafik büyütmek, hesabı hem pahalı hem yavaş yapar; kaba hesabı bant genişliği hesaplayıcı ile yapabilirsiniz.

Sıkça Sorulan Sorular#

Günde 10.000 ziyaretçi paylaşımlı hosting ile kalkar mı#

Evet, tam sayfa önbellek çalışıyorsa rahatlıkla kalkar. 10.000 ziyaretçi, oturum başına 2,2 sayfa ve %92 önbellek isabetiyle zirve saatte yaklaşık 1–2 eşzamanlı PHP isteği üretir; bu, tipik 20'lik giriş süreci limitinin çok altındadır. Aynı trafik önbelleksiz bir WooCommerce mağazasından geliyorsa hesap 15–20 worker'a kadar çıkar ve paylaşımlı hosting sınırda kalır. Kararı ziyaretçi sayısına değil, kendi access log'unuzdan ölçtüğünüz dinamik istek oranına ve PHP süresine göre verin.

Sınırsız trafik yazan pakette neden 508 hatası alıyorum#

Çünkü 508 hatası trafikle değil, eşzamanlılıkla ilgilidir. "Sınırsız trafik" ifadesi aylık aktarılan veri miktarına dair bir taahhüttür; 508 ise hesabınızın aynı anda çalıştırabileceği giriş süreci (EP) sayısının dolduğunu söyler. Ayda 500 GB veri aktarabilirsiniz ama tek bir saniyede 25 dinamik istek gelirse limit dolar ve o andaki ziyaretçiler hata görür. Çözüm daha fazla "trafik" değil, önbellekle dinamik istek sayısını düşürmek ya da eşzamanlılık limiti daha yüksek bir ortama geçmektir.

Eşzamanlı ziyaretçi ile eşzamanlı istek aynı şey mi#

Hayır, ikisi çok farklıdır ve karıştırılması yanlış paket seçiminin en sık nedenidir. Sitenizde aynı anda 200 kişi geziniyor olabilir ama bu kişilerin çoğu o an sayfayı okuyordur; sunucudan bir şey istemezler. Sunucuyu yalnızca istek gönderilen milisaniyeler meşgul eder. 200 eşzamanlı okuyucu, ortalama 45 saniyede bir sayfa değiştiriyorsa saniyede yaklaşık 4,4 istek üretir; 0,6 saniyelik PHP süresiyle bu sadece 2,7 eşzamanlı worker demektir.

Ortalama PHP süresini paylaşımlı hostingte nasıl ölçerim#

En pratik yol, sunucu yanıt süresini tarayıcının geliştirici araçlarından ya da bir hız testi aracından okumaktır. Ağ sekmesinde ana HTML belgesinin "Waiting (TTFB)" değeri, PHP süresi artı ağ gecikmesini verir; aynı ölçümü sunucuya coğrafi olarak yakın bir noktadan yaparsanız ağ payı 30–60 ms'ye iner ve kalan kısım büyük ölçüde PHP süresidir. Daha kesin ölçüm için oturum açık ve kapalı hâlde, önbelleğe düşmeyen bir sayfada (örneğin ?nocache=1 parametresiyle) beş ölçüm alıp ortancasını kullanın.

Hosting paketimi büyütmek mi önbellek kurmak mı daha mantıklı#

Önbellek neredeyse her zaman önce denenmelidir, çünkü hesabı çarpımsal olarak değiştirir. Tam sayfa önbellek dinamik istek oranını %90'ın üzerinde düşürür; paket yükseltmesi ise size tipik olarak EP limitinde bir–iki kat artış sağlar. Önbelleği kurmadan paket büyütmek, aynı israfı daha büyük bir kutuda tekrarlamaktır. İstisna, trafiğin ağırlıklı olarak önbelleklenemeyen sayfalardan (sepet, üyelik, ödeme) gelmesidir; orada önbelleğin kaldıracı düşük olduğu için doğrudan kaynak artışı gerekir.

VDS'e geçince kaç ziyaretçi kaldırabilirim#

Bu soru da doğrudan cevaplanamaz; VDS'in kaldırdığı şey ziyaretçi değil, eşzamanlı worker sayısıdır. 4 vCPU ve 8 GB RAM'li bir VDS'te güvenli üst sınır kabaca 20–24 eşzamanlı PHP worker'dır. Ortalama PHP süreniz 0,6 saniyeyse bu saniyede yaklaşık 35 dinamik istek eder; zirve saatte 126.000 dinamik istek, %90 önbellek isabetiyle günde birkaç yüz bin sayfa görüntülemeye karşılık gelir. Kendi PHP sürenizi ve önbellek oranınızı yerine koyup aynı zinciri tersten yürütün.

Ziyaretçi sayım artınca ilk hangi kaynak dolar#

Vakaların büyük çoğunluğunda ilk dolan kaynak eşzamanlı süreç (EP) limitidir, ikinci sırada CPU (SPEED) gelir. Disk alanı ve bant genişliği çok daha geç doyar; bu ikisi yüzünden paket yükselten site oranı azdır. E-ticarette sıralama değişebilir: filtreli arama ve rapor sorguları çalıştıran mağazalarda önce disk G/Ç (IO) tıkanır ve site "sunucu yavaş" gibi görünür. Hangi limitin dolduğunu tahmin etmek yerine cPanel'in kaynak kullanımı grafiğinden okuyun.

Kapanış#

Kaç ziyaretçi için hangi hosting paketi sorusunun tek doğru cevabı bir aralık değil, bir hesaptır: günlük ziyaretçiyi sayfa görüntülemeye, onu zirve saatteki istek hızına, onu da ortalama PHP süresiyle çarparak eşzamanlı worker sayısına çevirin. Çıkan sayı 15'in altındaysa paylaşımlı hosting fazlasıyla yeterlidir; 15–25 aralığındaysa önce önbellek ve sorgu optimizasyonu denenmelidir; sürekli 25'in üzerindeyse ya da mimarî ihtiyaçlar varsa kendi kaynaklarınızın olduğu bir sunucuya geçmenin zamanı gelmiştir. Bu dört sayının hepsi kendi access log'unuzda ve cPanel kaynak kullanımı ekranınızda mevcut — tahmine gerek yok.

Hesabınızı yaptıktan sonra doğru rafı seçmek kolaydır: düşük eşzamanlılıklı tanıtım ve blog siteleri için paylaşımlı hosting paketleri, WordPress'e özel önbellek yapılandırmasıyla gelen WordPress hosting, sepet ve ödeme trafiği önbelleklenemediği için daha yüksek eşzamanlılık isteyen mağazalar için e-ticaret hosting, PHP-FPM havuzunu kendiniz boyutlandırmak istediğinizde ise VDS sunucu paketleri uygun başlangıç noktalarıdır. Hangi rafta olduğunuzdan emin değilseniz hosting seçici aracıyla ölçtüğünüz değerleri girip karşılaştırabilirsiniz.