Bir haber sitesi büyürken en büyük sürpriz, “iyi giden” günlerde değil; bir anda patlayan trafikte gelir. Bir son dakika haberi, sosyal medyada viral olan bir video ya da push bildirimle tetiklenen bir akış… Bir bakmışsın: sayfa açılmıyor, admin panel kilitlenmiş, reklam gösterimleri düşmüş, okuyucu “site çöktü” diye başka kaynağa kaçmış.

İşte bu noktada “haber sitesi hosting” seçimi, sadece fiyat/alan hesabı olmaktan çıkar. Sorun artık kapasite değil; ani yükü taşıma, hatayı yönetme ve geri toparlama kabiliyetidir. Bu yazıda “yüksek trafikte VDS sunucu” ihtiyacının hangi eşikte başladığını, yavaşlığın gerçek kaynağını nasıl okuyacağını ve kesintisiz geçişi nasıl planlayacağını net bir omurgayla anlatacağım.

Haber sitesinde “trafik patlaması” nasıl olur? (sosyal medya, son dakika, push)

Trafik patlaması genelde “tek bir kaynaktan” gelmez. Aynı dakika içinde birkaç kanal üst üste biner.

Sosyal medya en sert dalgayı yaratır. Bir paylaşım X’te trend olur, Instagram hikâyelerinde dolaşır, Facebook gruplarında zincirlenir. Bu trafik “dağınık” gibi görünse de ortak özelliği şudur: Aynı URL’ye, aynı başlığa, aynı görsellere anlık yük bindirir. Cache yoksa, her istek sunucunun içine tokat gibi iner.

Son dakika haberi ise davranışı değiştirir. Kullanıcı sadece tek sayfayı değil, ana sayfayı yeniler, kategoriye gider, “gelişmeleri canlı” takip eder. Yani tek bir yazı değil; sayfa listeleri, widget’lar, “en çok okunanlar”, etiket sayfaları aynı anda ısınır. Veritabanı sorguları artar, PHP worker’lar dolmaya başlar.

Push bildirimse en “eş zamanlı” yükü getirir. 50 bin aboneye aynı anda giden bir push, saniyeler içinde binlerce istek demektir. Burada sorun genellikle bant genişliği değil; TTFB’nin uzaması ve 5xx hatalarının fırlamasıdır. Çünkü aynı anda sunucu tarafında işlem kuyruğu oluşur.

Trafiğin karakterini bilmek, çözümü de belirler. Viral içerik “statik ağırlıklı”dır; son dakika “dinamik ağırlıklı”dır; push ise “eş zamanlı yoğunluk” demektir.

Yavaşlığın kaynağı: TTFB ve 5xx hataları ne anlatır?

Yavaşlık hissi tek bir ölçü değildir. İki gösterge özellikle belirleyicidir: TTFB ve 5xx.

TTFB (Time To First Byte), tarayıcı isteği attıktan sonra ilk baytın gelmesine kadar geçen süredir. Yani “sunucu cevap vermeye ne kadar hızlı başladı?” sorusunun karşılığıdır. Haber sitelerinde TTFB yükseliyorsa, çoğu zaman problem ağ değil; sunucu tarafındaki işlem süresidir: PHP, veritabanı, cache eksikliği, worker yetersizliği.

5xx hataları (özellikle 502/503/504) ise “sunucu tarafında yetişememe” sinyalidir. 502 genelde upstream (PHP-FPM, uygulama) ile web sunucusu arasındaki kopmaları; 503 yoğunlukta servis verememeyi; 504 ise zaman aşımını işaret eder. Bu hatalar sıklaştığında “site yavaşladı”dan öte, “site güvenilmezleşti” algısı oluşur.

TTFB + 5xx birlikte artıyorsa, bu çoğu zaman kapasite sınırına yaklaşıldığını gösterir. Burada küçük optimizasyonlar işe yarar ama bir noktadan sonra altyapı seviyesi değişmelidir.

Paylaşımlı hosting neden pik saatlerde tökezler?

Paylaşımlı hosting, normal günlerde “idare eder” performans verebilir. Ama pik saatlerde aynı makinedeki komşuların hareketleri seni doğrudan etkiler.

En temel problem “kaynağın paylaşılması”dır. CPU zamanı, RAM, disk IO ve hatta bazı limitler aynı havuzun içinde paylaştırılır. Senin siten büyüdükçe, aynı havuzun içindeki dalgalanmalara daha hassas hale gelirsin. Bir komşu hesap backup alır, bir diğeri yoğun cron çalıştırır, bir diğeri saldırı alır… Sen de etkilenirsin.

İkinci problem, kaynak limitlerinin “sabit tavan” gibi çalışmasıdır. Paylaşımlı paketlerde genelde eş zamanlı proses/entry process/IO limitleri vardır. Trafik patlayınca limitler dolup taşar ve sistem “kibarca” yavaşlamak yerine hata üretmeye başlar.

Üçüncü problem, haber sitesinin doğasıdır. Ana sayfa ve kategori sayfaları çok sık güncellenir; yorumlar, reklam script’leri, görsel optimizasyonu, cache temizliği gibi işlemler üst üste biner. Paylaşımlıda bu karmaşık yük, pik anlarda daha hızlı duvara çarpar.

Bu yüzden “haber sitesi hosting” tarafında asıl soru şudur: “Günlük ortalama trafikte iyi miyim?” değil, “en kötü 10 dakikayı sağ salim atlatabiliyor muyum?”

Darboğazı bul: CPU mu RAM mi IO mu? (3 kısa paragraf)

CPU darboğazı genelde dinamik sayfalarda ortaya çıkar. PHP işleme süresi uzar, aynı anda gelen istekler kuyruk oluşturur. CPU %90+ seviyelerde uzun süre kalıyorsa ve load average yükseliyorsa, “işlem gücü” yetmiyor demektir.

RAM darboğazı çoğu zaman sessiz başlar. Cache (Redis/Memcached), database buffer’ları, PHP süreçleri RAM’i doldurur. RAM yetmeyince swap devreye girer; işte o an her şey ağırlaşır. Sayfalar açılır ama “geç” açılır. TTFB’nin uzaması ve admin panelin sürünmesi tipik belirtidir.

Disk IO darboğazı haber sitesinde çok yaygındır. Çünkü görseller, loglar, cache dosyaları, veritabanı dosyaları aynı diski döver. IO bekleme (iowait) yükselir, 504’ler görülür. NVMe gibi hızlı depolama ve doğru cache stratejisi burada fark yaratır.

Darboğazı doğru teşhis etmezsen, “CPU artırdım olmadı” veya “RAM yükselttim ama 502 devam ediyor” döngüsüne girersin.

Ne zaman VDS’e geçilir? (3 net belirtiyle karar eşiği)

VDS’e geçiş kararını “içgüdüyle” değil, üç net belirtiyle vermek daha doğru.

Birinci belirti: Pik anlarda 5xx hataları başlıyorsa. Haftada bir bile olsa 502/503/504 görüyorsan, bu artık “küçük ayar” seviyesi değildir. Çünkü okur kaçışı ve SEO tarafında olumsuz sinyal riski artar.

İkinci belirti: TTFB pik saatlerde kalıcı şekilde yükseliyorsa. Örneğin normalde 200–400 ms bandında olan ilk bayt süresi, son dakika akışında saniyelere çıkıyorsa; işlem kuyruğu oluşuyor demektir. Burada VDS ile izole kaynak + daha güçlü cache kombinasyonu ciddi rahatlama sağlar.

Üçüncü belirti: Paylaşımlıda limit duvarına çarpıyorsan. Entry process, concurrent connection, CPU/IO limit uyarıları, sık sık “resource limit is reached” mesajları… Bunlar “paket büyüt”ten ziyade “mimarî değiştir” işaretidir.

Bu eşiklerden bir veya ikisi sende varsa, “yüksek trafikte VDS sunucu” seçeneğini masaya koymanın zamanı gelmiştir. Bu noktada hızlı bir çıkış yolu arıyorsan, ölçeklenebilir altyapı için hızlı hosting çözümleri tarafına da bakabilirsin.

VDS seçerken pratik kriterler (CPU/RAM/IO + lokasyon + destek)

VDS seçerken kağıt üstündeki “çekirdek sayısı” tek başına anlamlı değildir. Haber sitesinde performans, birkaç ana parametrenin dengesiyle çıkar.

CPU tarafında önemli olan, tek çekirdek performansı ve sürdürülebilir yük altındaki davranıştır. Özellikle PHP tabanlı CMS’lerde (WordPress gibi) ani yoğunlukta hızlı cevap için CPU kritik rol oynar. Ama CPU iyi diye her şey bitmez.

RAM tarafında hedef, hem uygulama süreçlerine hem de cache katmanına yer açmaktır. Redis/Object Cache, veritabanı buffer’ları ve PHP süreçleri aynı anda “nefes” ister. RAM düşükse sistem swap’a düşer, bu da gecikmeyi katlar.

IO tarafı ise haber sitelerinde çoğu zaman gizli kahramandır. NVMe depolama, hızlı okuma-yazma ve düşük gecikme demektir. Özellikle görsel yoğun sitelerde ve veritabanı aktivitesi yüksek yapılarda IO düşükse, en güçlü CPU bile bekler.

Lokasyon konusu, okur kitlene göre net bir çarpan oluşturur. Türkiye ağırlıklı trafik için Türkiye’ye yakın, düşük gecikmeli hatlar TTFB’ye olumlu yansır. CDN kullanıyor olsan bile dinamik sayfaların ana cevabı yine sunucudan gelir.

Son olarak destek… Trafik patlaması “mesai saatine” göre gelmez. 03:00’te viral olursun, 09:00’da reklamveren şikayet eder. Bu yüzden VDS sağlayıcısının hızlı müdahale ve doğru yönlendirme kabiliyeti, teknik spesifikasyon kadar önemlidir.

Bu kriterleri pratikte toparlamak istersen, kaynak dengesi ve ölçeklenebilirlik odağıyla yüksek trafikte VDS sunucu seçeneklerini inceleyip kendi trafik senaryona göre bir plan çıkarabilirsin.

Kesintisiz geçiş planı (TTL, son senkron, test, geri dönüş)

Geçişi doğru planlarsan, haber sitesi taşınırken “yayın kesmek” zorunda kalmazsın. Burada amaç, hem DNS gecikmesini azaltmak hem de veri kaybı riskini sıfıra yaklaştırmaktır.

İlk adım TTL’dir. Domain DNS kaydının TTL değerini, geçişten en az 24 saat önce düşürmek işi kolaylaştırır. TTL düşük olunca, IP değişimi daha hızlı yayılır. Böylece “bazıları eski sunucuyu görüyor” karmaşası azalır.

İkinci adım test ortamıdır. Yeni VDS üzerinde siteyi “hosts dosyası” ile test etmek, canlıya dokunmadan sorunları yakalamanı sağlar. Bu aşamada cache, PHP sürümü, veritabanı ayarları, görsel yolları, cron işleri ve eklentiler kontrol edilir. Haber sitesinde özellikle “ana sayfa bileşenleri” ve “kategori sayfaları” mutlaka test edilmelidir; çünkü en yoğun yük buralardan gelir.

Üçüncü adım son senkron ve kısa kilit penceresidir. Eğer siten sürekli içerik girilen bir yapıya sahipse (dakikada haber giriliyor gibi), son senkronu planlamak şarttır. İçerik ekibini 5–10 dakikalık “yayın donması”na almak, veritabanını son kez senkronlamak ve ardından DNS’i çevirmek çoğu senaryoda sorunsuz geçiş sağlar. Bu süreyi doğru zamanda (trafik nispeten sakin bir aralıkta) yapmak daha güvenlidir.

Dördüncü adım geri dönüş planıdır. Her şey iyi gider gibi görünse bile, “geri dönüş” senaryosunu hazır tutmak gerekir. DNS’i eski IP’ye döndürme, eski sunucuyu kısa süre daha ayakta tutma, kritik hatalarda hızlı rollback… Bunlar panik anında değil, geçişten önce yazılmış olmalı.

Geçiş bittikten sonra da iş bitmez. İlk 24–48 saat izleme (TTFB, 5xx, CPU/RAM/IO), cache hit oranları, veritabanı sorgu yükü ve loglar düzenli kontrol edilmelidir. Trafik patlaması tekrar geldiğinde, “bu sefer hazır” olmanın tek yolu budur.

Haber siteleri için büyüme, çoğu zaman “bir anda” olur. O yüzden altyapı kararını, trafik patladıktan sonra değil; patlamaya en yakın eşikte vermek daha az maliyetli ve daha az risklidir. Eğer şu an TTFB ve 5xx tarafında sinyaller görüyorsan, “haber sitesi hosting” tarafında bir üst seviyeye geçmek ve “yüksek trafikte VDS sunucu” ile izole kaynaklara sahip olmak, yayın güvenilirliğini belirgin şekilde artırır.