Web Siteniz Neden Yavaş? Hosting Kaynaklı 8 Olası Sebep

Paylaşımlı Kaynaklar Yetersiz veya Aşırı Yüklü

Paylaşımlı hostingde aynı fiziksel sunucunun CPU, bellek ve disk kaynakları birçok hesap arasında bölüşülür. Sağlayıcılar adil kullanım için hesap başına CPU, bellek, G/Ç ve eş zamanlı işlem sınırları koyar. Sınır aşıldığında istekler kuyruğa girer, yavaşlar veya hata döner. Ayrıca aynı sunucudaki yoğun bir komşu hesap, ortak kaynakları sıkıştırabilir. Buna “komşu etkisi” denir ve sunucu başına yerleştirilen hesap yoğunluğuna bağlı olarak değişir.

• Gece hızlı, gündüz veya yoğun saatlerde yavaş sayfa.
• Ziyaretçi sayısı artmadığı halde zaman zaman yavaşlama.
• Bazı altyapılarda 503 veya “Resource Limit Is Reached” (508) hataları.
• Panelde CPU, bellek veya eş zamanlı işlem sınırı grafiklerinin sürekli dolu görünmesi.

Aynı sayfanın TTFB değerini günün farklı saatlerinde 10'ar kez ölçün. Aşağıdaki döngü bunu tek komutta yapar:

for i in $(seq 1 10); do curl -o /dev/null -s -w "%{time_starttransfer}\n" https://ornek.com; done

Sonuçları saatlerle birlikte not edin. Yoğun saatlerde değerler belirgin biçimde artıyorsa ve panel kaynak grafikleriyle aynı döneme denk geliyorsa kaynak paylaşımı güçlü bir şüphelidir.

• Önbellekle PHP ve veritabanı çalışmasını azaltarak kaynak tüketimini düşürün.
• Gereksiz eklentileri ve ağır zamanlanmış işleri kaldırın.
• Sağlayıcıdan hesabınızın hangi sınırlara takıldığını ve sınır değerlerini yazılı olarak isteyin.
• Sınırlar sürekli aşılıyorsa daha yüksek bir pakete veya kaynakların size ayrıldığı bir VPS ya da VDS'e geçmeyi değerlendirin.

Yavaş Depolama ve Disk G/Ç Darboğazı

Dinamik bir site her istekte dosya okur ve veritabanı, verilerini diskte tutar. Bu nedenle disk gecikmesi doğrudan sunucunun yanıt süresine yansır. Mekanik diskler (HDD) rastgele okuma ve yazmada SSD ve NVMe diskler kadar hızlı değildir. Paylaşımlı ortamlarda ise yoğun G/Ç yükü, diski kullanan herkesin işlemini kuyruğa sokabilir.

• Yönetim paneli ve veritabanı ağırlıklı sayfalar özellikle yavaş.
• Yedekleme çalışırken veya büyük dosya yüklenirken site belirgin biçimde yavaşlıyor.
• Önbellek sayesinde hızlı gelen sayfalar, önbellek boşken çok yavaş.

Paylaşımlı hostingde sunucuya erişiminiz olmadığı için sağlayıcıya depolama türünü (HDD, SSD, NVMe) ve G/Ç sınırlarını sorun. VPS veya VDS kullanıyorsanız sunucuda şu komutlarla CPU bekleme süresini ve disk doluluğunu izleyebilirsiniz (iostat, sysstat paketiyle gelir):

vmstat 1 5
iostat -x 1 5

• vmstat çıktısındaki wa değeri, CPU'nun disk beklemesinde geçirdiği oranı gösterir. Sürekli yüksekse disk darboğazı vardır.
• iostat çıktısında %util değerinin sürekli %100'e yakın olması ve await süresinin yüksek olması, diskin işleri yetiştiremediğini gösterir.

• SSD veya NVMe depolama sunan bir hizmete geçin.
• Gereksiz dosyaları, eski yedekleri ve log dosyalarını temizleyin. Çok sayıda küçük dosya hem G/Ç'yi hem dosya sayısı (inode) sınırını zorlar.
• Önbellek kullanarak her istekte diske gitmeyi azaltın.

Eski veya Yanlış Yapılandırılmış PHP

WordPress, WooCommerce ve birçok web uygulaması PHP ile çalışır. Yeni PHP sürümleri genellikle eski sürümlere göre belirgin biçimde daha verimlidir; desteği bitmiş sürümler ise güvenlik yamaları da almaz. Sürümün yanında yapılandırma da önemlidir. OPcache kapalıysa PHP dosyaları her istekte yeniden derlenir. PHP-FPM çalışan sayısı (worker) yetersizse eş zamanlı istekler kuyrukta bekler.

• Yönetim paneli ve işlem yoğun sayfalar (sepet, ödeme, arama) yavaş.
• Yoğunlukta zaman zaman 502 veya 504 hataları.
• Sağlayıcının panelinde yalnızca eski PHP sürümlerinin seçilebilmesi.

PHP sürümünü hosting panelinden veya WordPress'teki Araçlar > Site Sağlığı > Bilgi ekranından görebilirsiniz. Komut satırı erişiminiz varsa sürümü ve önemli ayarları şu komutlarla listeleyin:

php -v
php -i | grep -e opcache.enable -e memory_limit -e max_execution_time

Komut satırı PHP'sinin ayarları, web sunucusunun kullandığı ayarlardan farklı olabilir; kesin değerler için phpinfo() çıktısına veya panelin PHP ayarları ekranına bakın.

• Temanız ve eklentilerinizle uyumlu en güncel PHP sürümüne geçin. Geçişten önce yedek alın ve mümkünse bir test kopyasında deneyin.
• OPcache'in etkin olduğundan emin olun.
• Bellek sınırının (memory_limit) sitenizin ihtiyacına uygun olduğunu doğrulayın.
• Sağlayıcı güncel PHP sürümlerini sunmuyorsa bunu hosting değişikliği için ciddi bir gerekçe sayın.

Veritabanı Sunucusu Darboğazı

Dinamik sayfaların büyük bölümü yanıt üretirken veritabanını sorgular. Yavaş sorgular, devasa tablolar ve eksik indeksler çoğu zaman site kaynaklıdır. Ancak hosting tarafında da darboğaz oluşabilir: veritabanı sunucusu paylaşımlı ve bağlantı sayısı sınırlıdır, bellek ayarları düşüktür veya veritabanı, uygulamadan ayrı bir makinede olduğu için her sorguya ağ gecikmesi eklenir.

• Statik dosyalar hızlı gelirken dinamik sayfaların ilk yanıtı geç geliyor.
• Yönetim paneli, arama ve filtreleme işlemleri özellikle yavaş.
• “Too many connections” veya “Error establishing a database connection” hataları.

WordPress kullanıyorsanız Query Monitor gibi bir geliştirici eklentisi hangi sorguların ne kadar sürdüğünü gösterir. Kendi sunucunuzda yetkili bir kullanıcıyla çalışan sorguları ve yavaş sorgu kaydını şu komutlarla inceleyebilirsiniz:

SHOW FULL PROCESSLIST;
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;

İlk komut o an çalışan sorguları listeler. Sonraki iki komut, 1 saniyeden uzun süren sorguların kaydedilmesini sağlar. Bu ayarlar sunucu yeniden başlatılınca sıfırlanır ve yetki gerektirir.

• Önce sitenizdeki veritabanı yükünü azaltın: eski sürüm kayıtlarını, süresi dolmuş geçici verileri ve gereksiz otomatik yüklenen seçenekleri temizleyin.
• Nesne önbelleği (Redis veya Memcached) kullanabiliyorsanız tekrar eden sorguların yükünü azaltın.
• Veritabanı ayarlarını değiştirmeniz gerekiyorsa ve paylaşımlı ortamda bu mümkün değilse, yapılandırmayı özelleştirebileceğiniz bir VPS veya VDS değerlendirin.

Sunucu Tarafı Önbellek Eksikliği

Önbellek, hızlandırmanın en etkili ve en ucuz yoludur. Sayfa önbelleği, hazır HTML'i doğrudan sunarak PHP ve veritabanı çalışmasını tamamen atlar. Nesne önbelleği sorgu sonuçlarını bellekte tutar. OPcache ise derlenmiş PHP kodunu saklar. Bazı sağlayıcılar bunları sunucu düzeyinde sunar (LiteSpeed önbelleği, Nginx FastCGI önbelleği veya Varnish gibi). Sunucu düzeyinde önbellek yoksa geriye yalnızca eklentiler kalır; bunlar çoğu zaman daha fazla kaynak tüketir ve daha az verimlidir.

• Aynı sayfayı arka arkaya istediğinizde ikinci yanıt hızlanmıyor.
• Her ziyaretçi için sayfa baştan üretiliyor ve CPU kullanımı trafikle doğru orantılı artıyor.
• Yanıt başlıklarında önbellek bilgisi görünmüyor.

Yanıt başlıklarını inceleyin. Cache-Control, Age veya sağlayıcıya özgü X-Cache benzeri başlıklar önbelleğin çalıştığına işaret eder:

curl -sI https://ornek.com

Aynı adresi iki kez ölçün. İlk istek sonrası TTFB belirgin biçimde düşüyorsa önbellek çalışıyordur.

• Sağlayıcınızın sunucu düzeyindeki önbellek seçeneklerini öğrenin ve etkinleştirin.
• Uyumlu bir önbellek eklentisini sağlayıcının önerdiği ayarlarla kullanın.
• Veritabanı yükü yüksek sitelerde nesne önbelleğini ekleyin.
• Sağlayıcı hiçbir önbellek çözümü sunmuyorsa ve eklentilerle de yeterli iyileşme alamıyorsanız bu, altyapı değişikliği için bir gerekçedir.

Web Sunucusu ve Protokol Yapılandırması

Sayfanın sunucudan tarayıcıya nasıl taşındığı da hızı belirler. HTTP/2 ve HTTP/3 aynı bağlantı üzerinden birçok dosyayı paralel taşır; HTTP/1.1 ise çok dosyalı sayfalarda daha yavaştır. Gzip veya Brotli sıkıştırma, HTML, CSS ve JavaScript dosyalarının boyutunu küçültür. TLS 1.3 güvenli bağlantı kurulumunu kısaltır. Bu ayarlar sunucu tarafında yapılır ve sağlayıcı yapılandırmasına bağlıdır.

• Tarayıcı geliştirici araçlarının Ağ sekmesinde protokol sütununda http/1.1 görünüyor.
• Metin tabanlı dosyalar sıkıştırılmadan, tam boyutunda iniyor.
• Toplam süre ile TTFB arasındaki fark büyük.

Aşağıdaki ilk komut kullanılan HTTP sürümünü (1.1, 2 veya 3) yazdırır. İkinci komut ise sıkıştırma istediğinizde sunucunun content-encoding başlığıyla yanıt verip vermediğini gösterir:

curl -sI -o /dev/null -w "%{http_version}\n" https://ornek.com
curl -sI -H "Accept-Encoding: gzip, br" https://ornek.com

• Sağlayıcıdan HTTP/2 veya HTTP/3 ve sıkıştırma desteğini kontrol etmesini veya etkinleştirmesini isteyin.
• Statik dosyalar için bir CDN kullanarak hem protokol hem de mesafe avantajından yararlanın.
• Bu temel özellikler sağlayıcınızın altyapısında desteklenmiyorsa yeni bir altyapıyı değerlendirin.

Sunucu Konumu ve Ağ Gecikmesi

Bir sayfa açılırken tarayıcı ile sunucu arasında birkaç gidiş-dönüş yaşanır: DNS çözümü, TCP bağlantısı, TLS el sıkışması ve sonra asıl istek. Her gidiş-dönüş, sunucuyla aranızdaki mesafe ve ağ yönlendirmesi kadar sürer. Ziyaretçilerinizin çoğu Türkiye'deyse ve sunucunuz uzak bir ülkedeyse bu gecikme her adımda tekrar eder. Yönlendirme kalitesi de mesafe kadar etkilidir: coğrafi olarak yakın bir sunucuya, kötü bir rota üzerinden ulaşılabilir.

• Sayfa içeriği hızlı iniyor ama ilk yanıt gecikiyor.
• Ölçümler farklı şehir ve ülkelerden alındığında büyük fark gösteriyor.
• Zaman dökümünde bağlantı ve TLS süreleri yüksek.

Başta verdiğimiz zaman dökümü komutuyla bağlantı ve TLS aşamalarına bakın. Ek olarak sunucuya ulaşma süresini ve rotayı şu komutlarla görebilirsiniz (Windows'ta ping -n 5 ve tracert kullanın):

ping -c 5 ornek.com
traceroute ornek.com

Bazı sunucular ICMP isteklerine yanıt vermez; bu durumda ping sonuç göstermeyebilir. Farklı konumlardan test yapan hizmetler bu açıdan daha güvenilirdir.

• Hedef kitlenize yakın bir veri merkezinde barındırılan bir hizmet seçin.
• Statik dosyalar için bir CDN kullanın. CDN, dinamik sayfaların sunucu yanıt süresini tek başına düzeltmez; önbelleğe alınabilen içerikte etkilidir.
• Güvenilir ve hızlı bir DNS sağlayıcısı kullanın.

Arka Plan Yükü: Botlar, Yedekler ve Zamanlanmış İşler

Hosting kaynaklarınızı yalnızca gerçek ziyaretçiler kullanmaz. Arama motoru botları, ölçüm ve tarama araçları, zararlı botlar, giriş sayfasına yönelik parola denemeleri, yedekleme işlemleri ve cron işleri aynı CPU, bellek ve disk kaynaklarını tüketir. Sağlayıcı düzeyinde bot filtreleme veya hız sınırlama yoksa bu yük doğrudan gerçek ziyaretçilerin hızına yansır.

• Ziyaretçi sayısı düşükken kaynak kullanımı yüksek.
• Yavaşlama her gün aynı saatlerde, örneğin yedekleme veya cron saatlerinde yaşanıyor.
• Erişim kayıtlarında tek bir IP'den çok sayıda istek ve yoğun wp-login.php veya xmlrpc.php trafiği.

Erişim günlüklerine ulaşabiliyorsanız en çok istek yapan IP adreslerini listeleyin. Aşağıdaki komut Nginx günlüğü içindir; Apache'de yol genellikle /var/log/apache2/access.log'dur ve yollar kuruluma göre değişir:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n 10

Paylaşımlı hostingde ham erişim günlüklerini genellikle panelden indirebilirsiniz. Yedekleme ve zamanlanmış görev saatlerini de panelden kontrol edin.

• Yedekleme ve ağır cron işlerini düşük trafikli saatlere kaydırın.
• Kötü niyetli ve gereksiz bot trafiğini web uygulaması güvenlik duvarı veya CDN düzeyinde filtreleyin.
• Gereksiz zamanlanmış işleri kaldırın veya seyrekleştirin.
• Sağlayıcınızın bot filtreleme ve hız sınırlama imkânlarını sorun.