Trafiğin büyümeye başladığı o eşik var ya… İşte “VPS mi VDS mi?” sorusu genelde tam orada sorulur. Başta her şey yolundayken, bir gün aniden sayfalar geç açılır, yönetim paneli ağırlaşır, kampanya saatlerinde site “donmuş” gibi olur. Hele içerik tarafında düzenli üretim varsa—2013’ten beri yayınını sürdüren gundemvan.com gibi sürekliliği olan sitelerde—bu dalgalanma daha görünür hale gelir. Çünkü okur alışır; hız düşünce hemen fark eder.
Bu yazıda, “kâğıt üstünde” değil; gerçek kullanım senaryoları üzerinden anlatacağım. VDS sunucu tarafı niye daha stabil, VPS ne zaman yeterli, trafik büyürken hangi işaretler “artık yükselt” diyor… Hepsi netleşsin.
VPS ve VDS farkı: tahsisli kaynak ne demek?
VPS, çoğu zaman iyi bir başlangıçtır. Sanallaştırma katmanında size belli CPU/RAM/disk alanı tanımlanır; pratikte bir sunucunun “paylaşımlı ama daha güçlü” versiyonu gibi düşünülür. Fakat birçok VPS modelinde kaynaklar paylaşım mantığıyla yönetilir. Yani kağıt üzerinde size ayrılan RAM var; ama CPU tarafında ya da disk IO tarafında aynı node’daki diğer müşterilerin davranışı performansı etkileyebilir.
“Tahsisli kaynak” dediğimiz şey, özellikle CPU çekirdeği ve IO performansı gibi kritik alanlarda, başkasının yükünün sizi aşağı çekmemesi demektir. VDS yaklaşımı genelde burada güçlenir: daha izole bir kaynak seti, daha tahmin edilebilir performans, daha stabil pik saat davranışı.
Kısaca: VPS ile iyi giderken sorun “ortalama hız” değil, “en kötü an”dır. Trafiğin tepe yaptığı, botların yokladığı, içerik paylaşıldığı, yorumların arttığı, cache’in dolduğu o anda sistemin verdiği tepki, altyapının kalitesini belirler. Bu yüzden karar verirken “ortalama” yerine “pik saat” performansını düşünmek gerekir.
Trafik büyürken en sık yapılan 3 hata (paragraf anlat)
Birinci hata, sorunu sadece “hosting paketi küçük” sanmak. Oysa yavaşlık bazen yanlış cache kurgusundan, bazen görsel optimizasyon eksikliğinden, bazen de veritabanı şişmesinden çıkar. Paket yükseltmek geçici rahatlama sağlar ama kök sebep kalır.
İkinci hata, trafik artınca her şeyi aynı anda değiştirmek. Tema değişir, eklentiler eklenir, CDN açılır, PHP sürümü atlanır, veritabanı ayarları kurcalanır… Sonra performans artmış mı azalmış mı anlaşılmaz. Ölçmeden yapılan her hamle, sorunu büyütür.
Üçüncü hata, “şimdilik idare eder” diyerek stabiliteyi ertelemek. Düzenli yayın yapan sitelerde erteleme pahalıya patlar. Çünkü trafik artışı lineer gelmez; bir içerik tutar, sosyalde yayılır, bir anda yük 5 katına çıkar. O an sistem düşerse, sadece o günün trafiğini değil, güveni de kaybedersiniz.
Darboğaz analizi: CPU/RAM/IO hangisi?
Performans konuşurken üç kelime her şeyi özetler: CPU, RAM, IO. Hangisi tıkanıyorsa, kullanıcı “site yavaş” der; ama çözüm her seferinde aynı değildir.
CPU darboğazı genelde şu tabloda çıkar: aynı anda çok sayıda PHP isteği işleniyordur, arka planda cron işleri dönüyordur, arama/filtreleme gibi işlemler yoğunlaşmıştır. CPU %90-100 bandında uzun süre kalıyorsa, “çekirdek” tarafı yetmiyor olabilir.
RAM darboğazı daha sinsi ilerler. Cache mekanizması RAM ister, veritabanı buffer ister, PHP-FPM süreçleri RAM ister. RAM dolunca sistem swap’e düşer; işte o an “her şey ağırlaştı” hissi başlar. Swap’e düşen bir site, özellikle pik saatlerde gözle görülür şekilde sürünür.
IO (disk okuma/yazma) darboğazı ise modern sitelerin gizli düşmanıdır. Çok eklentili WordPress, yoğun log yazımı, veritabanı tablolarının büyümesi, yedekleme sırasında aynı diske yük binmesi… IO tıkanınca CPU boşta bile kalsa site ağırlaşabilir. Bu yüzden karar verirken sadece “kaç GB disk” değil, diskin performans karakteri önemlidir.
Bu analizi düzgün yapmak için ölçüm şart. Sunucu tarafında anlık yük, iowait, memory pressure, veritabanı sorgu süreleri gibi metrikler; uygulama tarafında TTFB, cache hit rate, yavaş sorgular gibi veriler birlikte okunmalı. “VPS mi VDS mi” kararının en sağlıklı zemini budur.
Paylaşımlı/VPS’te komşu etkisi ve stabilite sorunu
Komşu etkisi (neighbor effect) basit bir şey değil; özellikle trafik büyüyünce “şans” faktörünü artırır. Aynı fiziksel node üzerinde bir müşteri yoğun IO yapıyorsa, disk kuyruğu uzar. Bir başkası CPU’yu zorluyorsa, scheduler daha agresif paylaşım yapar. Siz çok iyi optimize etmiş olsanız bile, aynı node’daki farklı davranışlar sizin “en kötü anınızı” etkiler.
Bu durum küçük sitelerde fark edilmeyebilir. Çünkü yük düşükken sistem toleranslıdır. Ama trafik büyüyüp eş zamanlı istek sayısı arttıkça, milisaniyelik gecikmeler bile zincirleme birikmeye başlar. Kullanıcı giriş yapamaz, admin panel gecikir, checkout sayfası takılır, API timeout verir… Sonra konu “hız” olmaktan çıkar, “stabilite”ye döner.
Burada VDS sunucu yaklaşımının en büyük getirisi, öngörülebilirliktir. Bir site sahibi için en kıymetli şey, “bugün iyi, yarın kötü” değil; “her gün benzer” davranıştır. Çünkü içerik planı, reklam bütçesi, SEO ivmesi, hatta müşteri destek yükü bile buna göre şekillenir.
Bu noktada altyapı seçimi yaparken, sadece paket adı değil; sağlayıcının kaynak izolasyonu, IO altyapısı, node yoğunluğu, izleme ve müdahale süreçleri gibi detaylar da önem kazanır. Eğer hosting tarafında farklı paketleri inceleyeceksen, başlangıç için şu sayfaya göz atabilirsin: güvenli hosting paketleri
Ne zaman VDS mantıklı? (süreklilik + pik saat belirtileri)
VDS’e geçişin “tek bir doğru zamanı” yok. Ama sürekliliği olan projelerde işaretler çok nettir. 2013’ten beri düzenli yayın yapan bir platform düşün: İçerik arşivi büyür, kategori sayısı artar, iç link ağı genişler, arama trafiği oturur. Bu büyüme, altyapıyı her ay biraz daha zorlar.
Şu belirtiler tekrarlıyorsa, VDS sunucu ciddi şekilde mantıklıdır: Pik saatlerde TTFB yükseliyordur; yönetim paneli özellikle yoğun saatlerde yavaşlıyordur; cache açık olmasına rağmen sayfa ilk açılışları ağırdır; cron işleri içerik yayınını geciktiriyordur; veritabanı sorguları “aniden” uzuyordur; kampanya/haber patlamasında 502/504 hataları görülüyordur.
Bir diğer kritik işaret, “aynı ay içinde dalgalanma.” Bir gün uçuyor, ertesi gün sürünüyor. İçerikte bir değişiklik yok, tema aynı, eklentiler aynı… Bu tür dalgalanma çoğu zaman altyapı kaynak paylaşımından ve IO baskısından çıkar. İşte tam burada, VDS’e geçerek bu değişkenliği azaltmak mümkün olur.
Özellikle yayıncılıkta şunu unutmamak gerekir: Trafik sadece kullanıcıdan gelmez. Botlar, indeksleme, sosyal medya önizleme crawler’ları, API çağrıları… Hepsi arka planda yük bindirir. Trafik büyüdükçe bu “görünmez trafik” de artar. VDS, bu yükü daha kontrollü taşıma şansı verir.
Paket seçimi: CPU/RAM dengesi ve IO beklentisi
Paket seçerken insanların en sık düştüğü tuzak “RAM’i büyüteyim, tamamdır” yaklaşımıdır. RAM önemli, evet. Ama CPU ve IO dengesi bozuksa, RAM yükseltmek sadece semptomu biraz geciktirir.
İçerik ağırlıklı ve dinamik sayfaları olan projelerde CPU çekirdeği, PHP-FPM işçisi sayısı, veritabanı performansı bir bütündür. Çok ziyaretçili ama iyi cache’lenmiş bir sitede CPU ihtiyacı daha dengeli kalabilir; ancak admin panel, arama, filtreleme, üyelik, yorum gibi dinamik parçalar artıyorsa CPU ihtiyacı yükselir.
RAM tarafında ise iki şeye dikkat: Cache stratejin ve veritabanı buffer ihtiyaçların. Objeyi RAM’de tutan cache kurguları (Redis/Memcached gibi) RAM ister. Veritabanı “diskten okumak” yerine “RAM’den okumak” ister. RAM azsa, sistem swap ile sizi yavaşlatır.
IO beklentisi ise genelde konuşulmuyor ama en kritik kısım o. Yedekleme alırken site yavaşlıyorsa, medya kütüphanesi büyüyünce panel ağırlaşıyorsa, import/export işlemleri can yakıyorsa IO tarafına daha fazla önem vermek gerekir. Bu yüzden VDS seçerken “NVMe var” demek tek başına yetmez; IO’nun sürdürülebilirliği ve node üzerindeki baskı önemlidir.
Bu çerçevede VDS tarafını incelemek istersen, özellikle performans beklentisi olan projeler için şu sayfa iyi bir referans olur: performans odaklı VDS sunucu
Taşıma: kesinti olmadan geçiş akışı
Geçişin en büyük korkusu “site kapanır mı?” sorusudur. Doğru planla, kesinti minimuma iner; hatta çoğu senaryoda kullanıcı fark etmeden geçiş yapılabilir.
İlk adım, yeni sunucuyu “boş” bırakmamaktır. Aynı PHP sürümü, aynı web sunucusu kurgusu, aynı veritabanı sürümü, aynı cache katmanı… Eski ortamın birebir benzeri hazırlanır. Çünkü sürüm farkları, geçişin en gizli sorun kaynağıdır.
İkinci adım, veri senkronizasyonunu katmanlı yapmaktır. Önce dosyalar taşınır (media, tema, eklenti). Sonra veritabanı alınır. Ardından kısa aralıklarla incremental senkronizasyon yapılır. Böylece finalde taşınacak veri miktarı küçülür.
Üçüncü adım, DNS ve TTL planlamasıdır. TTL değerini önceden düşürmek, yönlendirme değiştiğinde yayılım süresini kısaltır. Geçiş gecesinde “herkes farklı yere gidiyor” kaosu azalır. Ayrıca mümkünse geçişten önce staging alanında test yapılır; ödeme sayfası, üyelik, form gönderimi, API endpoint’leri tek tek kontrol edilir.
Dördüncü adım, “yazma işlemlerini” yönetmektir. Yorum, sipariş, kayıt gibi yazma işlemleri varsa, kısa bir bakım modu penceresi ya da çift-yazma stratejisi düşünülür. İçerik odaklı sitelerde bu daha kolaydır; e-ticaret tarafında daha planlı olmak gerekir.
Son adım, izleme. Geçiş bitti sanıldığı an, aslında yeni başlar. Error log, slow query log, kaynak kullanımı, cache hit oranı, 404/500 hataları… İlk 24-48 saat yakından izlenir. Çünkü küçük ayarlar, büyük fark yaratır.
Trafik büyürken doğru karar, “en pahalı paket” değil; projenin ritmine uygun, stabil ve ölçülebilir bir altyapıdır. Özellikle sürekliliği olan yayın projelerinde, VPS mi VDS mi sorusunun cevabı çoğu zaman “stabiliteye ne kadar değer veriyorsun?” noktasında yatar. Eğer pik saatlerde dalgalanma yaşıyorsan, kaynak paylaşımı seni zorluyorsa ve büyümeyi ciddiye alıyorsan, VDS sunucu tarafı genellikle daha güvenli bir yol çizer.
