Sunucu Bant Genişliği Planlaması: Gerçek İhtiyaç Tespiti

Sunucu bant genişliği planlaması, birçok barındırma (hosting) sorununu daha baştan engeller: sayfa yüklenme süreleri artmadan kapasiteyi korursunuz, “beklenmedik limit aşıldı” sürprizleri yaşamazsınız ve maliyeti gereksiz yere büyütmezsiniz. Bu rehberde, bant genişliğini tahmin etmek yerine gerçek ihtiyaç tespiti yapmanızı sağlayacak hesap yöntemlerini ve pratik kontrol adımlarını anlatıyorum. Sonunda, seçtiğiniz VDS/VPS planının hangi trafik senaryosunda kaç GB/ay tüketebileceğini netleştireceksiniz.

Bant genişliği neyi ifade eder? GB/ay mantığını doğru kurun

Bant genişliği (bandwidth), sunucunuza gelen ve/veya sunucudan giden veri miktarıdır. Hosting sağlayıcıların çoğu bunu aylık GB/ay olarak raporlar. Burada kritik nokta şudur: Trafik ölçümü “toplam veri aktarımı” olarak sayılabilir; bazı sağlayıcılar sadece giden (outbound) trafiği, bazıları hem giriş hem çıkışı dahil eder. Bu nedenle planlama yaparken şu iki soruyu mutlaka netleştirin:

• Limit hesabı giden trafik üzerinden mi, toplam trafik üzerinden mi yapılıyor?
• CDN, cache, yedekleme (backup) gibi bileşenler trafik limitine dahil mi?

Bu ayrım yapılmadan “trafik tahmini” gerçeği yansıtmaz. Örneğin sadece inbound ölçen bir sistemde, sitenizin dışarıya verdiği görseller/indirilebilir dosyalar limitten bağımsız olabilir; tersinde ise tablo bütünüyle değişir.

Planlama için temel trafik bileşenleri

Gerçek ihtiyaç tespiti için trafik genelde şu kalemlere ayrılır:

• Web içeriği: HTML, CSS/JS, görseller, video parçaları, font dosyaları
• API çağrıları: REST/GraphQL yanıtları, webhook yanıtları
• Dosya indirme: PDF, ZIP, görsel arşiv, tema/e-klasör paketleri
• Otomatik süreçler: bot taramalarının yarattığı trafik, bot koruma sonuçları
• Yedekleme akışları: sunucudan dış depolamaya (S3/R2/B2) ya da dış sistemlere aktarılan veri
• E-posta: SMTP/IMAP akışlarının yarattığı trafik (hosting türüne göre ayrı limitler olabilir)

Gerçek ihtiyacı hesaplamanın 3 adımı

Bant genişliği planlama, iki aşamalı bir süreçtir: önce ölçüm verisi toplayın, sonra senaryolaştırıp limit çıkarın.

1) Mevcut trafiği gerçek metriklerle ölçün

Eğer siteniz halihazırda yayındaysa en doğru yöntem “tahmin” değil, mevcut ölçüm almaktır.

Şu kaynaklar işe yarar:

• Web sunucusu log’ları (Nginx/Apache access log)
• Kontrol paneli/istatistik ekranı (cPanel/DirectAdmin veya sağlayıcı sayacı)
• CDN varsa CDN panelindeki transfer istatistikleri
• Uygulama katmanında istek boyutları (örn. API response payload ölçümü)

Burada hedefiniz “tüm ay” değil, ortalama günlük ve tepe (peak) davranışı görmektir. En azından son 30 gün için şunları çıkarın:

• Ortalama günlük transfer (GB/gün)
• En yüksek günlük transfer (GB/gün)
• Trafiğin bileşenleri (özellikle görsel/video payı)

Örnek yaklaşım: Son 30 günün toplamını alıp 30’a böldüğünüzde ortalama; gün gün en yüksek değeri aldığınızda tepe değer elde edilir. Tepe değeri, bant genişliği planını “gerçek hayat koşullarında” doğrular.

2) Birim maliyeti doğru görün: GB/ay yerine istek başına veri

Bazı sistemlerde aylık tek rakam yeterli değildir. Örneğin e-ticaret sitelerinde görseller ve ürün stok değişimleri trafik dalgalandırır. Bu durumda “istek başına veri”yi anlamak gerekir.

Pratik metrikler:

• Sayfa görüntüleme başına ortalama veri (MB/PV): HTML + JS/CSS + görsellerin etkisi
• API çağrısı başına ortalama veri (KB/call): response boyutu
• İndirme başına veri (MB/download): dosya boyutu

Bunları hesaplamak için iki yol vardır:

• Tarayıcı ağ (network) paneli ile örnek kullanıcı akışı incelemek
• Sunucu tarafında response boyutlarını analiz etmek

Özellikle görsel/video trafiğinde “tekrar eden dosyalar” cache ile azalır. Bu yüzden cache hit oranı (örn. CDN cache) belirleyicidir.

3) Senaryo üretin: büyüme, kampanya ve bot etkisi

Bant genişliği planı sadece “ortalama”ya göre yapılmamalıdır. Aşağıdaki senaryoları sayısallaştırın:

• Normal ay: ölçülen ortalama
• Kampanya ayı: trafiği %50-200 artıran dönem
• Tepe an: 1-3 saatlik ani sıçrama
• Bot/örümcek: kötü niyetli tarama veya yanlış yapılandırılmış crawler
• Yedekleme gecesi: dış depoya aktarımlar

Bu senaryolarda iki katsayı belirleyin:

• Trafik artış katsayısı (ör. kampanya için 1.5)
• Veri başına artış (ör. video oynatımı başladıysa MB/PV artar; 1.2 gibi)

Böylece tepe aylık tahmininizi daha sağlam kurarsınız.

Somut hesap şablonu: GB/ay tahmini

Aşağıdaki formül, farklı trafik türlerini tek çatı altında toplamanıza yardımcı olur.

Temel formül

• Aylık bant genişliği (GB/ay) ≈ Ortalama günlük transfer (GB/gün) × 30 × Güvenlik katsayısı

Güvenlik katsayısı, ölçüm kalitesine göre seçilir:

• Sadece ortalama kullandıysanız: 1.2
• Ortalama + tepe kullandıysanız: 1.05-1.1
• CDN cache ve bot koruma davranışı net değilse: 1.2-1.3

Bileşen bazlı hesap (daha doğru)

• Web trafik: (PV/ay) × (MB/PV) / 1024
• API trafik: (call/ay) × (KB/call) / 1024
• İndirme: (download/ay) × (MB/download)
• Yedekleme: (backup GB/gün) × gün sayısı

Sonra hepsini toplarsınız.

Önemli tuzaklar: “Grafikte görünen trafik” her zaman gerçek transfer değildir

Bant genişliği planlarken sık yapılan hataları netleştireyim.

CDN ve cache’in etkisi

CDN kullanıyorsanız bant genişliği iki şekilde etkilenir:

• Statik içerik CDN’de kaldığı için origin sunucudan çıkış azalır
• Ancak CDN’den kullanıcıya giden trafik bazen ayrı raporlanır ve “origin limitine dahil olmayabilir”

Bu nedenle şunu yapın: Sağlayıcının limit paneli ile CDN panelini karşılaştırın. Origin tarafında düşüş var ama CDN tarafında yüksek çıktı varsa, planınızı origin limitine göre yapmanız gerektiğini anlarsınız.

TLS/SSL, HTTP/2/HTTP/3 ve tekrarlar

TLS şifreleme bant genişliğini doğrudan aynı oranda artırmaz; fakat yeni bağlantı kurulumu, handshake ve HTTP/1.1 kullanımında tekrar gönderimler trafik profilini değiştirir. Özellikle düşük cache ile çalışan dinamik sayfalarda fark görünür.

Hedefiniz:

• Statikte mümkün olan max cache header (Cache-Control) kullanmak
• HTTP/2 veya HTTP/3 etkinleştirmek (sağlayıcı desteğine bağlı)
• Görsel sıkıştırma ve boyutlandırma yapmak

Otomatik yedekleme ve dış depolama

Yedek (backup) transferi bant genişliğine ciddi yük bindirebilir. Eğer yedekleri her gece şifreli tarball olarak dış depoya gönderiyorsanız, “dosya sayısı az ama boyutu büyük” senaryosunda aylık maliyet artar.

Bu konuda kontrol listesi:

• Yedekleme sıklığı (günlük/haftalık)
• Yedek boyutu (GB)
• İteratif (incremental) yedek var mı, yok mu
• Sağlayıcı yedek transferini bant genişliği limitine dahil ediyor mu

Hangi planı seçmelisiniz? Limit + performans birlikte düşünülmeli

Bant genişliği sadece limit değil, performans davranışını da etkileyebilir. Bazı sağlayıcılar limit aşıldığında hız kısıtı uygular. Diğerleri ise sadece ekstra ücret çıkarır. “Aşınca ne oluyor?” sorusunu dokümandan öğrenin.

Pratik seçim kılavuzu (net karar kriterleri)

Aşağıdaki tablo, ölçümlerinizi bant genişliği planı seçimine bağlar.

İdeal güvenlik marjı

Net bir kural olarak şunu uygulayın:

• Eğer son 30 gün içinde tepe günler %30’dan fazla sapıyorsa: güvenlik katsayısı 1.2
• Tepe/ortalama farkı %10-20 bandındaysa: 1.1 yeterlidir
• Yedekleme/indirilebilir dosyalar belirleyici ise: 1.2-1.3

Yüksek bant genişliği neden sorun çıkarır? (Sadece “limit” değil)

Limit aşımı sadece kesintiyle sonuçlanmaz. Birçok sistemde bant genişliği yetersizliği şu sonuçları doğurur:

• TTFB/ilk yanıt gecikmesi artar (özellikle origin yüklüyse)
• İndirmeler yarıda kalabilir
• Video stream/segment dağıtımı bozulur
• API istemcileri timeout yaşar

Özellikle eş zamanlı kullanıcı sayısı artınca “aynı aylık toplam veri” farklı etkiler yaratır. Bu yüzden tepe saat mantığı önemlidir.

Bant genişliğini düşürme (aynı planla daha çok iş)

İhtiyacı azaltmak, plan büyütmekten genellikle daha hızlı sonuç verir. En etkili optimizasyonlar şunlardır:

• Görselleri doğru boyuta indir (responsive image) ve sıkıştır
• Statik içerikte cache sürelerini netleştir (Cache-Control, ETag)
• CDN cache’ini doğru yapılandır (cache hit oranı)
• API response boyutunu küçült (gereksiz alanları döndürme)
• Video için chunk/codec uyumunu kontrol et
• Botları gerçek zamanda engelle (rate limit, WAF)

Bu adımların ortak etkisi: Aynı ziyaret sayısında MB/PV’yi düşürmek.

Kontrol listesi: Plan seçmeden önce 10 dakika denetim

• CDN açık mı ve statik içerik doğru cache ediliyor mu?
• Cache hit oranı artıyor mu (özellikle görsellerde)?
• Büyük indirme dosyaları için ayrı URL/pattern var mı?
• Yedekleme saatleri bant yoğun saatlerle çakışıyor mu?
• Bot trafiği loglarda belirgin mi?
• API response payload’larında gereksiz veri var mı?

Ölçüm sonrası yeniden planlama: Süreklilik şart

Bant genişliği planlaması tek seferlik bir iş değildir. 11.11. gibi dönemsel yoğunluklar, kampanya günleri veya yeni ürün eklemeleri MB/PV’yi değiştirir.

Bu yüzden her ay şunları yapın:

• Planlanan GB/ay ile gerçekleşen GB/ay farkını hesaplayın
• Tepe günlerin neden yükseldiğini (kampanya, içerik türü, video vs.) not edin
• Bir sonraki ay için güvenlik katsayısını güncelleyin

Sonuç

Gerçek bant genişliği ihtiyacını doğru tespit etmek için önce mevcut transferi ölçün, sonra PV/api/indirme/yedek bileşenlerini senaryolaştırın ve plan seçiminde tepe günleri hesaba katın. Benim önerim: Mevcut veriniz varsa son 30 günün ortalaması ve en yüksek gününü birlikte alın; CDN varsa origin limitini esas alın; yedek transferini ayrıca kalem olarak ekleyin. Bu adımları tamamladığınızda, doğru VDS/VPS veya web hosting bant genişliğini sayısal olarak netleştirirsiniz ve limit kaynaklı performans sorunlarını önceden engellersiniz.