Hosting Yükseltme: Hosting Planınızı Gerçekten Ne Zaman Yükseltmelisiniz?

Site yöneticilerinin en yaygın hatalarından biri, site yavaşlar yavaşlamaz hemen hosting yükseltmeye yönelmeleridir; oysa vakaların önemli bir kısmında sorun sitenin kodundan, eklentilerden veya ağır veritabanı sorgularından kaynaklanır ve daha pahalı bir plan sorunu yalnızca birkaç ay erteler. Öte yandan bazı siteler, gerçek çözüm hosting yükseltmesi olduğu halde aylarca 508 Resource Limit Reached hatası ve aralıklı kesintilerle boğuşur. Bu makalede kaynak yetersizliğinin gerçek belirtilerini tanımayı, somut sayılar ve araçlarla karar vermeyi ve paranızı doğru yere harcamayı öğreneceksiniz.

Hosting Kaynak Yetersizliğinin Gerçek Belirtileri

Her şeyden önce bu belirtileri birbirinden ayırt edin. Bazı işaretler neredeyse her zaman kaynak yetersizliğine işaret eder:

• Yoğun saatlerde 508 veya 503 hatası: Site yoğun saatlerde (örneğin 18:00–22:00 arası) «Resource Limit Reached» hatası veriyor ama gece yarısı sorunsuz çalışıyorsa, Entry Processes veya CPU limitine ulaşmışsınız demektir.
• RAM kullanımının sürekli olarak %80'in üzerinde seyretmesi: Anlık yüksek kullanım normaldir, ancak gün boyunca ortalama bellek kullanımı %80'in üzerindeyse manevra alanınız yok demektir.
• PHP loglarında Allowed memory size exhausted hatası: Elbette önce php.ini içindeki memory_limit değerinin makul ayarlandığından emin olun (WordPress için genellikle 256M yeterlidir).
• Disk alanının veya Inode'un dolması: Inode kullanımı %90'ın üzerine çıktığında, disk alanı boş olsa bile yedekleme ve e-posta gönderimi aksar.
• I/O Throttling: CloudLinux'lu cPanel gibi panellerde IO Usage grafiği sürekli tavana yapışıyorsa, disk okuma-yazma darboğaz haline gelmiştir.

Buna karşın, «sitenin her saatte sürekli yavaş olması» veya «yalnızca belirli bir sayfanın yavaş olması» genellikle kaynak yetersizliğinin değil, yazılımsal bir sorunun işaretidir.

Yavaşlık Hostingden mi Koddan mı? Tespit Yöntemi

İşin en önemli kısmı burası. Üç basit test yapın:

1. Statik Dosyayı Dinamik Sayfayla Karşılaştırma

Hosting'in kök dizininde basit bir metin dosyası (örneğin test.txt) oluşturun ve yanıt süresini sitenin ana sayfasıyla karşılaştırın:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://example.com/test.txt
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://example.com/

Sonucun yorumu:

• Statik dosya 200 milisaniyenin altında ama ana sayfa 2 saniyenin üzerinde mi? Sorun hostingde değil, kod ve veritabanındadır.
• Statik dosya bile 800 milisaniye ila 1 saniye sürüyor mu? Sorun sunucu, ağ veya paylaşımlı hosting üzerindeki yükten kaynaklanmaktadır.

2. MySQL Yavaş Sorgu Loglarını İnceleme

SSH erişiminiz varsa (sanal sunucuda veya SSH sunan hostinglerde), Slow Query Log'u etkinleştirin:

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

Birkaç saat sonra logu inceleyin. 3 ila 10 saniye süren sorgular görüyorsanız (genellikle indekssiz wp_postmeta sorguları veya ürün filtreleme eklentilerinin aramaları), hosting yükseltmesi derdinize derman olmaz; sorgunun veya eklentinin düzeltilmesi gerekir.

3. Farklı Saatlerde Test Etme

Basit bir cron betiği veya ücretsiz bir izleme hizmetiyle sitenin TTFB değerini her 10 dakikada bir kaydedin. Sonucun deseni kendi başına bir teşhistir:

• Yalnızca yoğun saatlerde yavaşlık: Yük zirvesinde kaynaklar yetersiz kalıyor → hosting yükseltmesi mantıklıdır.
• Gün boyu tekdüze yavaşlık: Kodda yapısal bir sorun, önbellek eksikliği veya uygunsuz yapılandırma vardır.

Hosting Yükseltme Kararı Öncesinde Kaynakların Hassas Ölçümü

Asla «hisle» karar vermeyin; sayı toplayın. Gerçek kullanım desenini belirlemek için en az 7 günlük veriye ihtiyacınız var.

Paylaşımlı Hostingde (cPanel/DirectAdmin)

cPanel'de Resource Usage bölümüne (CloudLinux listesi) gidin ve şunları kontrol edin:

• CPU Faults ve Memory Faults: Son 24 saatte onlarcadan fazla Fault kaydedilmişse, istekler gerçekten limite dayanmış ve kullanıcılar hata görmüş demektir.
• Entry Processes: 20 eşzamanlı kullanıcıyla limite ulaşıyorsanız, ya betikler çok yavaştır ya da planın limiti düşüktür.

Sanal Sunucuda

Birkaç kilit komut:

# میانگین بار سیستم نسبت به تعداد هسته
uptime
# 14:32:01 up 45 days, load average: 3.85, 3.60, 3.20

# وضعیت حافظه
free -m

# فشار روی دیسک
iostat -x 5 3

Pratik kural: load average sürekli olarak CPU çekirdek sayısından yüksekse (örneğin 2 çekirdekli sunucuda 3,8), sunucu baskı altındadır. free -m çıktısında available değeri sürekli toplam RAM'in %15'inin altındaysa ve swap aktif olarak kullanılıyorsa, bellek darboğazdır. iostat çıktısında %util sütununun sürekli %80'in üzerinde olması diskin limite ulaştığı anlamına gelir.

Yükseltmeden Önce Bunları Yapın

Çoğu durumda bu önlemler kaynak kullanımını %30 ila %70 oranında azaltır:

1. Sayfa önbelleğini etkinleştirme: WordPress'te WP Super Cache veya (web sunucusu LiteSpeed ise) LiteSpeed Cache gibi eklentilerle. Önbelleğe alınmış bir sayfa 50 veritabanı sorgusu yerine sıfır sorgu çalıştırır.
2. Ağır ve kullanılmayan eklentileri kaldırma: Query Monitor eklentisiyle hangi eklentinin en fazla sorgu ve zaman tükettiğini inceleyin.
3. PHP sürümünü güncelleme: PHP 7.4'ten 8.2 veya 8.3'e geçiş genellikle CPU kullanımında %15 ila %30 azalma sağlar.
4. Zararlı botları engelleme: Erişim loglarını inceleyin; bazen sunucu yükünün yarısını işe yaramaz tarayıcı botlar üretir:

   awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20

   Birkaç belirli IP binlerce istek gönderiyorsa, bunları güvenlik duvarında veya .htaccess dosyasında engelleyin.
5. Veritabanı tablolarını optimize etme: Binlerce autoload satırı bulunan wp_options tabloları ve şişmiş wp_postmeta, RAM'in başlıca katilleri arasındadır.

Yaygın Hata: Sonu Gelmeyen Kademeli Yükseltmeler

Sıkça gördüğümüz yaygın bir hata: kod sorunu olan bir site her 6 ayda bir kademe yükseltme alır ve her seferinde yalnızca birkaç haftalık geçici iyileşme görür. Bir yükseltmeden sonra kaynak kullanımı, sitenin gerçek trafiği artmadığı halde bir-iki ay içinde tekrar limite ulaşıyorsa, sorununuz kaynak değildir; bellek sızıntısı, ağır cron görevleri veya indekssiz sorgulardır. Google Analytics ziyaret istatistiklerini kaynak kullanım grafiğinin yanına koyun: kullanım artışı trafik artışıyla orantılı olmalıdır.

Hosting Yükseltmesi Ne Zaman Doğru Karardır?

Şu koşullar bir arada sağlanıyorsa, gönül rahatlığıyla yükseltme yapın:

• Önbellekleme ve temel optimizasyonlar yapılmış ancak kullanım hâlâ yüksek.
• Kullanım deseni gerçek trafik artışıyla uyumlu (örneğin ziyaretler 2 katına çıkmış ve kullanım da yaklaşık 2 katına çıkmış).
• Yoğun saatlerde Fault veya 5xx hatası kaydediliyor.
• Statik dosya bile yavaş sunuluyor, yani altyapının kendisi baskı altında.

Yükseltme hedefini seçerken de dikkatli olun: darboğazınız CPU ise, daha fazla disk alanı olan değil, daha fazla çekirdeği olan bir plan alın. Paylaşımlı hostingde limite ulaştıysanız ve site gelir getiriyorsa, sanal sunucuya geçiş size kaynaklar ve yapılandırma üzerinde daha kapsamlı kontrol sağlar; ServerNet de hem paylaşımlı hosting hem de sanal sunucu alanlarında hizmet sunmaktadır ve geçiş öncesinde mevcut darboğazınız hakkında destek ekibiyle görüşebilirsiniz.

Özet

Hosting yükseltmesi hakkında doğru karar üç aşamadan oluşur: birincisi, statik dosya testi ve yavaş sorgu loglarıyla yavaşlığın hostingden mi yoksa koddan mı kaynaklandığını belirleyin; ikincisi, en az bir hafta boyunca CPU, RAM ve I/O kullanım verisi toplayın; üçüncüsü, para ödemeden önce önbellekleme ve temel optimizasyonları yapın. Gerçek trafik desenine ve sayılara dayanarak yapılan bir yükseltme yatırımdır; hata ayıklamaktan kaçmak için yapılan bir yükseltme ise yalnızca zaman satın almaktır.