Blog Sitesi İçin Hosting: Ne Kadar Kaynak Yeterli?

Blog sitesi hosting’i seçerken asıl zor konu, “yeterli kaynak” fikrini somut metriklere çevirmektir. Yanlış boyutlandırma; yavaş açılış, beklenmedik maliyet ve bakım sırasında servis kesintisi gibi sorunlar doğurur. Bu rehberde blog trafiğine göre CPU, RAM, disk (I/O) ve bant genişliğini nasıl hesaplayacağını, hangi eşiklerde VDS/VPS’e geçmenin doğru olacağını net örneklerle öğreneceksiniz. Ayrıca WordPress gibi dinamik bloglarda önbellek (cache), CDN ve yedekleme yaklaşımıyla kaynak gereksinimini nasıl düşüreceğinizi göreceksiniz.

1) “Yeterli”yi belirleyen 4 metrik: CPU, RAM, disk I/O, transfer

Bloglarda sorun çoğu zaman “toplam ziyaretçi”den ziyade işlem tipidir: aynı anda kaç istek (request) geliyor, hangi içerikler dinamik üretiliyor ve veritabanı ne kadar yükleniyor.

Aşağıdaki metrikleri birlikte düşünün: - CPU (işlemci zamanı): Özellikle arama, sıralama, form işlemleri ve WordPress eklentileri yoğun CPU kullanır. - RAM (cache ve PHP yükü): İstek başına PHP bellek kullanımı ve uygulama cache’i RAM ile sınırlanır. - Disk I/O (özellikle SSD): Veritabanı (MySQL/MariaDB) ve log/opsiyonel dosya işlemleri için kritiktir. Yetersiz IOPS, CPU/RAM yüksek olsa bile yavaşlatır. - Transfer/bant genişliği (bandwidth): Dosya boyutları (resim, tema, font, video varsa) ve sayfa boyutu büyüdükçe belirleyici olur.

Blogda “ortalama” değil “pik” daha önemlidir

Hosting seçerken tek bir ortalama değer yerine pik senaryosunu hedefleyin. Pik; sosyal medyadan gelen dalga trafik veya belirli bir makalenin keşfedilmesi sırasında oluşur.

2) Trafiği senaryolaştır: aylık ziyaret → günlük istek → eşzamanlılık

Hosting boyutlandırmasını netleştirmek için şu basit dönüşümle ilerleyin.

Temel varsayımlar

WordPress bloglarda bir ziyaret ortalama 1-2 sayfa geziyor varsayımıyla ilerleyin.
Sayfa başına ortalama dosya boyutu (özellikle görsel çoksa) yüksektir; CDN yoksa transfer artar.
Önbellek varsa (sayfa cache, object cache) dinamik işlem azalır.

Kullanacağınız pratik dönüşüm

Aylık ziyaret (Z) → günlük ziyaret (Z/30)
Sayfa görüntüleme: günlük istek ≈ günlük ziyaret × sayfa başı görüntüleme
Eşzamanlılık için pikte bir fraksiyon seçin: çoğu blogda pikte gelen isteklerin %1-%3’ü aynı anda çalışıyormuş gibi ele alınabilir.

Örnek (CDN + sayfa cache var): - Aylık 50.000 ziyaret → günlük ~1.667 ziyaret - Sayfa başı 1,5 → günlük ~2.500 istek - Pik saatinde (günde birkaç saat) eşzamanlılık için %2 örnek: aynı anda ~50 istek

Bu sayıyı kullanarak uygulamanın her istek için harcadığı CPU/RAM ihtiyacını hesaplarsınız.

3) Kaynak eşik tablosu: Blog trafiğine göre “yeterli” boyutlar

Aşağıdaki değerler, WordPress benzeri PHP + veritabanı çalışan bloglar için pratik başlangıç noktalarıdır. CDN, iyi cache ve optimizasyon varsa aynı trafik daha düşük kaynakla yönetilir; eklenti/tema yoğunluğu yüksekse bir üst sınıfa çıkmanız gerekir.

Not: Buradaki amaç “tek doğru” değil; doğru aralığı görmenizi sağlamaktır. Sağlayıcılar farklı performans ölçer kullandığı için tabloyu hedef olarak düşünün.

Aylık ziyaret	Önerilen kurgu	CPU hedefi (vCPU)	RAM hedefi	Disk (SSD) & I/O yaklaşımı	Transfer yaklaşımı
0 - 10.000	Paylaşımlı hosting + sayfa cache	-	-	Yüksek I/O şartı aramayın; kontrol paneli + yedekleme odak	CDN yoksa görselleri optimize edin
10.000 - 50.000	VPS/VDS’e geçişe hazırlık (VPS önerilir)	1-2 vCPU	1-2 GB	SSD; özellikle veritabanı için stabil IOPS	CDN ile sayfa boyutunu düşürün
50.000 - 150.000	Yönetimli VPS/VDS (managed)	2-3 vCPU	2-4 GB	SSD/NVMe tercih; DB için ayrı kaynak iyi olur	CDN şart seviyesine yaklaşır
150.000 - 400.000	VDS veya dedicated’e yaklaşım (ağır eklenti yoksa)	4 vCPU+	4-8 GB	NVMe; yüksek IOPS ve iyi kontrol panel/izleme	Alan adı başına (domain) boyut ve görsel stratejisi kritik
400.000+	Dedicated / ölçekli mimari	6 vCPU+	8 GB+	NVMe; gerekirse DB ayrımı	CDN + cache prewarming ile sürdürülebilirlik

WordPress blog için “RAM neden kritik?”

WordPress’te istek geldiğinde PHP çalışır, bazı eklentiler (arama, istatistik, sosyal paylaşım vb.) ek yük bindirir. RAM azaldıkça: - PHP işlemleri artan bekleme yaşar - Cache daha az çalışır - Basit yoğun anlarda zaman aşımı (timeout) görülür

Bu yüzden VDS/VPS planlarken RAM’i “boşta duran” değil, pik anlarını karşılayacak şekilde seçin.

Disk/IO neden CPU’dan önce hissedilir?

Veritabanı sorguları ve indeksler iyi değilse, veya disk yavaşsa kullanıcılar “CPU yüksek ama site yavaş” şeklinde algılar. Bu noktada sadece CPU/RAM değil, SSD/NVMe ve I/O kapasitesi belirleyicidir.

4) Cache, CDN ve eklentiler: ayni trafiğe farklı kaynakla yönetim

Blog için kaynak ihtiyacını en hızlı düşüren araçlar genellikle uygulama mimarisidir.

{H3} 4.1 Sayfa cache ile dinamik istekleri azaltın

En büyük farkı genellikle şunlar yaratır: - Sayfa önbelleği (page cache) - Nesne cache’i (object cache) - Gzip/Brotli + doğru HTTP cache başlıkları

Bu üçü, “her ziyaret bir PHP sayfası çalıştı” durumundan çıkarır.

Pratik kontrol listesi

Ana sayfa, kategori ve etiket sayfaları cache’leniyor mu?
Admin/oturum sayfalarında cache devre dışı kalıyor mu?
Eklenti sayısı ve işlevleri gereksiz mi? (özellikle her sayfada çalışan istatistik/analytics eklentileri)

{H3} 4.2 CDN ile transferi ve origin yükünü ayırın

CDN; görseller, CSS/JS ve statik içerikte transferi hafifletir. Köklü farklar: - Origin sunucuda bant genişliği düşer - Origin’ın eşzamanlı istek yükü azalır - Coğrafi gecikme (latency) düşer

Net ölçüm için şunu hedefleyin: - CDN devredeyken origin üzerindeki istek sayısı belirgin biçimde azalmalı - PageSpeed/TTFB iyileşmesi görülmeli

{H3} 4.3 Eklentiler kaynak tüketimini “katman katman” artırır

Özellikle şu tip eklentiler art arda geldiğinde CPU/RAM tüketimi hızlı yükselir: - Her sayfa açılışında ek sorgu yapan arama eklentileri - Tema içinde sürekli çalışan ağır slider/galeri scriptleri (sunucu değil ama sayfa maliyetini artırır) - İstatistik/loglama eklentileri (özellikle synkron yazma)

Bu nedenle “hosting yeterli mi?” sorusundan önce “hangi eklenti, hangi endpoint’i yüklüyor?” sorusuna cevap verin.

5) VDS/VPS ne zaman gerekir? Net geçiş kriterleri

Aşağıdaki eşikler oluştuğunda paylaşımlı hosting veya düşük kaynaklı VPS yerine daha kontrollü bir plan gerekir.

A) Zaman aşımı ve yüksek TTFB

Kullanıcıların rapor ettiği “site açılışları 5-10 saniye” gibi durumlar
Sunucu tarafında PHP-FPM veya uygulama timeout hataları
TTFB (ilk yanıt süresi) kalıcı olarak yükseliyorsa

B) CPU süreklilik sorunu

CPU sürekli %70-%90 bandında kalıyor ve cache açılışları iyileştirmiyor
Spike sonrası hızlı toparlamıyor

C) Veritabanı kilitlenmesi ve I/O bekleme

MySQL/MariaDB sorguları yavaşladığında “disk beklemesi” ile sonuçlanma
En basit sayfalarda bile yoğun sorgu görülmesi

D) Yedekleme ve güncelleme sırasında servis etkilenmesi

Yüksek trafik olmadan bile, sık güncelleme ve yedekleme işlemleri kaynak tüketir. Managed kurgu (managed VPS/VDS) ve düzgün planlama burada fark yaratır.

6) “Gereken” dediğiniz şeyin pratik hesabı: minimum plan + tampon

Hosting seçiminde en sık hata, “tam sınır” planı almak ve pikte taşmayı beklemektir.

Minimum + tampon modeli

Beklediğiniz pik eşzamanlılık üzerinden planı seçin.
Sonra kaynaklara %30-%50 tampon ekleyin.
Cache ve CDN ile düşen kaynak ihtiyacını ayrıca göz önünde bulundurun.

Örnek karar: - Pik saatinde ~50 eşzamanlı istek varsaydınız - Cache tam çalışıyorsa 2 vCPU/2 GB RAM aralığı yeterli olur - Ama eklenti artışı ve arama gibi dinamik endpoint’ler olasılığı varsa 3 vCPU/4 GB hedeflemek daha güvenli olur

Bant genişliği için net yaklaşım

Transferi sadece aylık ziyaret üzerinden okumayın. Sayfa boyutu (özellikle görseller) belirleyici olur. - Görsel formatı (WebP/AVIF) kullanın - Lazily load ve uygun boyut kırpma uygulayın - CDN ile statik dosyaları origin’den ayırın

7) Son kontroller: hosting satın almadan önce doğrulayacağınız 8 madde

Hosting “yetiyor” hissi için şu kontrolleri baştan isteyin veya test edin: - Sağlayıcı SSD/NVMe kullanıyor mu? - VPS/VDS’te CPU/RAM kaynakları “burst” ile mi sınırlı? - Disk I/O performansı garanti ediliyor mu (veya gerçek yaşam testleri var mı)? - Kontrol paneli veya erişim (SSH) ile yönetim mümkün mü? - Otomatik yedekleme (backup) frekansı net mi? Geri yükleme süresi (restore) nasıl? - Otomatik güncelleme/managed hizmet varsa kapsamı nedir? - Log erişimi ve izleme (monitoring) için ne sunuluyor? - İçerik ve statik dosyalar için CDN entegrasyonu kolay mı?

Sonuç

Blog siteniz için “ne kadar yeterli?” sorusunun doğru cevabı; yalnızca ziyaret sayısı değil, pik eşzamanlılık, cache/CDN etkisi ve veritabanı + disk I/O dengesidir. Önce trafik senaryosu çıkarın, sonra cache ve CDN ile kaynak ihtiyacını düşürün; en son olarak pik anlara %30-%50 tampon ekleyerek VDS/VPS boyutunu netleştirin. Bu yaklaşımı uygulayıp mevcut kurulumun TTFB, CPU ve veritabanı performansını ölçtüğünüzde “yeterli mi değil mi?” tartışması yerini somut kararlara bırakır.

Bir sonraki adım olarak: beklediğiniz aylık ziyaret aralığını seçin, yukarıdaki tabloya göre hedef kaynak bandını belirleyin ve kurulumdan itibaren 7 gün boyunca CPU, RAM, disk I/O ve transfer metriklerini izleyin. Metriğiniz sürekli pik sınırına yakınsa bir üst sınıfa geçmek için zaman ayırın.