Paylaşımlı hosting ile sunucu arasındaki seçim, trafik miktarıyla değil darboğazın nerede olduğuyla belirlenir. Günlük ziyaretçisi az ama sorgusu ağır bir site paylaşımlı pakette tıkanırken, ziyaretçisi çok ama sayfaları önbelleğe alınabilen bir site aynı pakette rahat çalışabilir. Bu yazı önce üç barındırma biçiminin gerçek farkını anlatıyor, sonra "yavaşlık" şikâyetinin kaynağını ayırmayı ve taşıma kararını hangi ölçümlere dayandırmak gerektiğini gösteriyor.
Üç barındırma biçiminin gerçek farkı
Üçünün farkı disk alanı değil, kaynak paylaşımı ve sorumluluk sınırı. Paylaşımlı hostingte işletim sistemi ve güncellemeler hizmet sağlayıcıda; VPS'te sunucunun içi size ait, bakımı da size ait; ayrı sunucuda donanım da tek müşteriye ayrılmıştır.
| Biçim | Kaynak | Bakım kimde | Tipik kullanım |
|---|---|---|---|
| Paylaşımlı hosting | Aynı makinede çok site, kaynak sınırlı | Hizmet sağlayıcı | Kurumsal tanıtım sitesi, blog, küçük katalog |
| VPS / bulut sunucu | Ayrılmış CPU ve bellek, büyütülebilir | Sizde ya da yönetilen hizmette | E-ticaret, panel, çok sayıda eş zamanlı işlem |
| Ayrı sunucu | Donanım tek müşteriye ait | Sizde ya da yönetilen hizmette | Ağır veri işleme, özel uyum gereksinimleri |
Bu tabloda görülmeyen ama kararı en çok etkileyen kalem bakım yükü. VPS'e geçmek "daha hızlı site" anlamına gelmez; güvenlik güncellemesi, yedek kurgusu ve izleme işi de sizin tarafınıza geçer. Yönetimi devralacak kimse yoksa, yönetilen bir pakette kalmak genelde daha sağlıklıdır.
Yavaşlık nereden geliyor? Dört ayrı yer
"Site yavaş" cümlesi tek bir sorunu anlatmaz. Önce yavaşlığın hangi aşamada olduğunu ayırmak gerekir:
- Sunucu yanıt süresi. İlk baytın gelmesi gecikiyorsa sorun barındırma, veritabanı sorgusu ya da uygulama tarafındadır.
- Varlık indirme. Yanıt hızlı geliyor ama sayfa ağır açılıyorsa, sorun görsel ve betik boyutlarındadır. Bu durumda sunucu büyütmek işe yaramaz.
- Tarayıcıda işleme. Dosyalar indi ama sayfa gecikmeli kullanılabilir hâle geliyorsa, ağır betikler ve üçüncü taraf kodları sıraya girmiş olabilir.
- Belirli sayfalarda yavaşlık. Sadece arama, filtreleme ya da panel sayfaları yavaşsa, sorun kapasite değil sorgu ve dizin tasarımıdır.
Ölçümü nasıl alacağınızı ve hangi değerin ne anlattığını Core Web Vitals yazısında anlattık; görsel kaynaklı yavaşlık için görsel hazırlığı yazısı doğrudan uygulanabilir bir kontrol listesi veriyor.
Bu ayrımı yapmanın pratik yolu şudur: aynı sayfayı oturum açmadan ve oturum açarak ölçün. Oturum açmadan hızlı, oturum açınca yavaş görünen bir sayfa önbelleğe alınabiliyor demektir; burada eklenecek kaynak değil, doğru kurgulanmış bir önbellek işe yarar. İki durumda da yavaşsa gecikme uygulamanın ya da veritabanının içindedir ve sunucu değişikliği ancak orada bir sınıra dayandığınızda sonuç verir.
Paylaşımlı paket ne zaman gerçekten yetmez?
Taşıma kararını tahminle değil belirtilerle vermek gerekir. Aşağıdakiler paketin sınırına gelindiğinin tipik işaretleridir:
- Trafik arttığı anlarda site tamamen yanıt vermiyor, trafik düşünce kendiliğinden düzeliyor.
- Hizmet sağlayıcı kaynak limiti aşımı uyarısı gönderiyor ya da süreçleri sınırlıyor.
- Yönetim paneli günlük işte (sipariş, iş emri, randevu girişi) kullanılamayacak kadar ağırlaşıyor.
- Uygulamanın ihtiyaç duyduğu bir bileşen ya da sürüm paylaşımlı pakette kurulamıyor.
- Veritabanı büyüdü ve yedekleme süresi, bakım penceresine sığmıyor.
Bu belirtiler yoksa ve şikâyet sadece "açılış biraz yavaş" ise, önbellek, görsel düzeni ve gereksiz eklentilerin temizliği sunucu değişikliğinden daha hızlı sonuç verir.
Taşımadan önce ölçülecek dört değer
Taşımaya karar verdiyseniz, yeni ortamı doğru boyutlandırmak için şu dört veriyi mevcut ortamdan toplayın:
- Eş zamanlı kullanıcı ve istek sayısı. Günlük toplam değil, yoğun saatteki değer belirleyicidir.
- Veritabanı boyutu ve en ağır sorgular. Büyüyen tablo hangisiyse, yeni sunucuda da aynı tablo tıkanır.
- Toplam dosya alanı ve büyüme hızı. Görsel ve belge yükleyen bir panel varsa alan ihtiyacı sabit kalmaz.
- Yedekleme ve geri dönüş süresi. Yedeğin alınma süresi değil, geri yüklenme süresi plan yapmanızı sağlar; bu konu yedekleme yazısında ayrıntılı.
Taşıma günü ve sonrası
Taşıma kararı ne olursa olsun, geçişin kendisi planlanmış bir iştir: yeni ortam hazırlanır, veri aktarılır, site yeni ortamda test edilir ve ancak sonra adres yönlendirmesi yapılır. Adres tarafının nasıl yürüdüğünü hosting taşıma yazısında bulabilirsiniz. Geçişten sonraki ilk hafta izleme haftasıdır: sunucu yanıt süresi, hata kayıtları, e-posta gönderimi ve arama tarafındaki tarama hataları birlikte takip edilir.
Geçiş tarihini seçerken işletmenin yoğun gününden kaçının. Kampanya haftası, ay sonu ya da sezon başlangıcı, sorun çıkması hâlinde en az hareket alanınız olan günlerdir. Sakin bir gün seçmek, geri dönüş gerekse bile kaybı küçük tutar.
Bir noktayı atlamamak gerekir: barındırma değişikliği kurumsal e-postayı da etkileyebilir. E-posta aynı alan adı üzerinden çalışıyorsa, taşımadan önce e-posta kayıtlarının nereyi gösterdiğini doğrulamak, taşıma sonrası "e-postalar gelmiyor" sorununu baştan keser.
Özet
- Kapasite kararı trafik sayısına değil darboğazın yerine bakar.
- Yavaşlığı dört aşamaya ayırın: sunucu yanıtı, indirme, tarayıcı işleme, tek tek sayfalar.
- Paylaşımlı paket yetmiyorsa belirti olur: kaynak limiti, yoğun saatte kesinti, panelin kullanılamaz hâle gelmesi.
- VPS ve ayrı sunucu, bakım sorumluluğunu da size geçirir; devralacak kimse yoksa yönetilen hizmette kalın.
- Taşımadan önce yoğun saat yükü, veritabanı boyutu, dosya alanı ve geri dönüş süresi ölçülür.
DigiWSS, site ve e-ticaret projelerinde barındırma kurgusunu ölçerek belirler, taşıma ve sonrasındaki izlemeyi de aynı plan içinde yürütür.