Paylaşımlı hosting mi, VDS mi? Taşınma zamanını gösteren beş sinyal

"Sitem yavaşladı, sunucuya geçmeli miyim?" sorusunun cevabı çoğu zaman hayır. Yavaşlığın kaynağı genellikle paylaşımlı barındırmanın sınırları değil, eklenti yükü, optimize edilmemiş sorgular veya işlenmemiş görsellerdir. Ama gerçekten paketin sınırına gelinen durumlar da vardır ve bunlar panelde ölçülebilir. Aşağıdaki beş sinyalden en az ikisi sizde varsa geçiş konuşulabilir.

İki hizmet arasındaki gerçek fark

Paylaşımlı barındırmada tek bir fiziksel sunucu üzerinde onlarca hesap aynı çekirdeği, aynı PHP kurulumunu ve aynı disk havuzunu kullanır. Kaynaklar CloudLinux LVE gibi teknolojilerle hesap başına bölünür: her hesabın kullanabileceği CPU yüzdesi, bellek miktarı ve eşzamanlı işlem sayısı (entry process) tanımlıdır. Sınırı aştığınızda site kapanmaz; istekler kuyruğa girer, yavaşlar ve yoğunlukta 508 hatası döner.

VDS'te ise sanallaştırma katmanı size ayrılmış çekirdek, ayrılmış bellek ve kendi işletim sistemi kurulumunuzu verir. Root yetkisi vardır; PHP sürümünü, web sunucusunu, servis yapılandırmasını siz belirlersiniz. Bunun bedeli, işletim sisteminin bakımını da üstlenmenizdir.

Sinyalleri aramadan önce: 15 dakikalık ön teşhis

Ölçüm yapılmadan verilen taşınma kararı tahmindir. Aşağıdaki üç adım çeyrek saat sürer ve vakaların önemli bölümünde sunucuyu tamamen aklar:

1. Trafiğin gerçek olduğunu doğrulayın. cPanel'de Raw Access ekranından ham erişim kaydını indirin ve en çok istek atan adresleri sayın: awk '{print $1}' access-ssl_log | sort | uniq -c | sort -rn | head -20. İlk sıradaki adres toplam isteğin onda birinden fazlasını yapıyorsa karşınızda ziyaretçi değil bir tarayıcı bot vardır.
2. Hangi adresin yorduğuna bakın. Aynı kaydı istenen yol sütununa göre sayın: awk '{print $7}' access-ssl_log | sort | uniq -c | sort -rn | head -20. Listenin başında /wp-cron.php, /xmlrpc.php ya da filtreli arama sonuç sayfaları varsa sorun kaynak miktarı değil yapılandırmadır.
3. Hata günlüğünü okuyun. cPanel Errors ekranındaki "Allowed memory size exhausted" ve "Maximum execution time" satırları tek bir eklentiyi gösteriyorsa yeni sunucu o eklentiyi düzeltmez, yalnız aynı hatayı daha uzun süre taşır.

Sinyal 1: Entry process ve CPU limiti sürekli doluyor

cPanel'de Resource Usage ekranı son 24 saat ve son ay için limit aşımlarını listeler. Ayda birkaç kez tepe noktasına değmek normaldir. Her gün, özellikle aynı saat diliminde EP limit ya da CPU limit satırında aşım görüyorsanız trafik paketin ölçüsünü geçmiş demektir. Burada dikkat: aşımların bir bot taramasından mı yoksa gerçek ziyaretçiden mi geldiğini ham erişim kaydından doğrulayın. Saatte binlerce istek atan bir tarayıcı botu, sunucu değil robots.txt ve hız sınırı sorunudur.

Sinyal 2: Yavaşlık ilk bayta kadar iniyor

Tarayıcı geliştirici araçlarında ağ sekmesini açıp ana belgenin TTFB (ilk bayta kadar geçen süre) değerine bakın. Statik bir sayfada TTFB 200 ms'in altındaysa sunucu yeterlidir; sorun ön yüzdedir. TTFB düzenli olarak 800 ms üzerindeyse ve önbellek kapalıyken bu değer 2–3 saniyeye çıkıyorsa uygulamanın ihtiyacı paketin verdiğinden fazladır. Önce uygulama tarafındaki hızlandırma adımlarını tüketin; ondan sonra donanım konuşulur.

Sinyal 3: Yazılım sürümü artık sizin kararınız olmalı

Belirli bir PHP eklentisine, farklı bir Node.js sürümüne, Redis'e, özel bir kuyruk işleyicisine veya kendi derlediğiniz bir kütüphaneye ihtiyacınız varsa paylaşımlı ortamda çözüm yoktur. Bunlar sistem genelinde kurulan bileşenlerdir ve tek bir hesap için değiştirilemez. Bu ihtiyaç ortaya çıktığı anda karar zaten verilmiştir.

Sinyal 4: Tek site değil, birden fazla müşteri projesi taşıyorsunuz

Ajanslarda sık görülen durum: on beş müşteri sitesi tek bir paylaşımlı hesapta, hepsi aynı cPanel altında. Bir müşterinin siteye eklediği ağır bir eklenti diğer on dördü yavaşlatır ve hesaplar arasında yetki ayrımı yoktur. Bu senaryoda VDS yerine bayi (reseller) hosting çoğu zaman daha doğru cevaptır: her müşteri kendi cPanel hesabını alır, kaynak kotaları ayrılır, sunucu bakımı sizde kalmaz.

Sinyal 5: Kesinti maliyeti sunucu farkını aşıyor

Aylık cirosunun önemli bölümünü siteden alan bir işletme için birkaç saatlik yavaşlık, paket farkının kat kat üzerinde kayıp demektir. Kesintinin size dakikada kaça mal olduğunu kabaca hesaplayın. Rakam, aradaki fiyat farkının aylık tutarını birkaç saatte karşılıyorsa tartışma bitmiştir.

Geçince ne devralıyorsunuz?

VDS ucuz bir yükseltme değil, farklı bir sorumluluk modelidir. Sunucu sizin olduğu an şu işler de sizin olur:

• Güvenlik güncellemelerinin düzenli uygulanması ve yeniden başlatma planlaması.
• Güvenlik duvarı, SSH sertleştirmesi ve saldırı denemelerine karşı hız sınırı. Başlangıç için ilk gün yapılacak işler listesi iyi bir çerçevedir.
• Yedeklerin alınması ve geri dönüş provasının yapılması.
• Servis izleme: disk dolduğunda, bellek tükendiğinde haber alacak bir düzenek.

Bu işleri üstlenecek teknik biriniz yoksa iki seçenek kalır: yönetilen hizmet almak ya da paylaşımlı ortamda kalıp uygulamayı optimize etmek. Yönetilmeyen bir sunucuyu sahipsiz bırakmak, paylaşımlı paketten daha riskli bir tercihtir.

VDS boyutunu tahminle değil ölçümle seçin

Geçişe karar verdiyseniz sıradaki yaygın hata, "ne olur ne olmaz" diyerek gereğinden büyük paket almaktır. Doğru boyutu paylaşımlı hesabın kendi verisi söyler:

• Bellek: Resource Usage ekranındaki tepe bellek kullanımını iki katına çıkarın, üzerine işletim sistemi ve veritabanı için 1 GB ekleyin. Tek bir WordPress sitesi için 2 GB çoğu zaman yeter; WooCommerce ve Redis birlikteyse 4 GB'tan başlayın.
• Çekirdek: Tepe saatteki eşzamanlı PHP işlemi sayısını dörde bölün. 8 eşzamanlı işlem görüyorsanız 2 çekirdek gerçekçi bir başlangıçtır.
• Disk: Bugünkü kullanımın iki katı. Yedekler, günlük dosyaları ve veritabanının bir yıllık büyümesi çoğu hesapta unutulan kalemlerdir.

Cloud ve VDS paketlerinde bu değerler sonradan büyütülebilir. Küçük başlayıp ölçüme göre artırmak, altı ay boyunca boş kapasiteye ödeme yapmaktan hem ucuz hem daha öğreticidir.

Karar tablosu

Bu karar ne zaman yanlış olur

Taşınmanın sonucu iyileştirmediği, hatta kötüleştirdiği üç durum var:

• Darboğaz koddaysa. Her istekte 400 sorgu çalıştıran bir tema, iki kat hızlı sunucuda yalnız iki kat az yavaş çalışır. Kazanç aylık fiyat farkını karşılamaz.
• Sunucuyu izleyecek kimse yoksa. Güncellenmeyen bir VDS birkaç ay içinde paylaşımlı paketten daha büyük bir güvenlik riskine dönüşür; paylaşımlı ortamda o güncellemeleri barındırma sağlayıcısı yapıyordu.
• Sorun ağdaysa. Ziyaretçilerin önemli bölümü yurt dışındaysa gecikmeyi düşüren şey çekirdek sayısı değil, doğru lokasyon ve içerik dağıtım ağıdır.

Ara basamağı atlamayın

Paylaşımlıdan doğrudan fiziksel sunucuya sıçramak yaygın bir aşırı tepkidir. Aradaki cloud ve VDS basamakları hem ölçek hem maliyet açısından çoğu büyüme eğrisine daha iyi oturur; kaynak yetmediğinde birkaç dakikada büyütülebilir, fazla geldiğinde küçültülebilir. Fiziksel sunucu, kaynak ihtiyacı öngörülebilir hale geldiğinde ve sanallaştırma katmanının maliyeti anlam kaybettiğinde mantıklıdır.

Kararı verirken tek bir soruyu net cevaplayın: darboğaz kaynakta mı, kodda mı? Ölçüm yapmadan verilen taşınma kararı, aynı sorunu daha pahalı bir sunucuda tekrar yaşamakla sonuçlanır.