Siteniz neden yavaş? Sunucuyu suçlamadan önce ölçün

"Site yavaş, sunucuyu yükseltelim" cümlesi teknik destek taleplerinde en sık gördüğümüz yaklaşımdır. Çoğu durumda yükseltme sorunu çözmez; çünkü darboğaz CPU veya RAM'de değildir.

Ölçmeden karar vermeyin. Aşağıdaki sıra, sorunu birkaç dakikada daraltır.

Önce TTFB'yi ölçün

İlk bayta kadar geçen süre (TTFB), sunucunun isteği işleyip yanıt vermeye başlaması için gereken süredir. Ölçmek için:

curl -o /dev/null -s -w "baglanti: %{time_connect}s\ntls: %{time_appconnect}s\nilk bayt: %{time_starttransfer}s\ntoplam: %{time_total}s\n" https://ornek.com

Sonucu şöyle okuyun:

• İlk bayt 200 ms altında: sunucu tarafı iyi durumda. Sorun büyük olasılıkla ön yüzde — görsel boyutları, render engelleyen betikler, üçüncü taraf etiketleri.
• İlk bayt 200–800 ms: uygulama katmanına bakın. Genellikle veritabanı sorguları.
• İlk bayt 800 ms üzeri: ciddi bir darboğaz var; aşağıdaki adımlara devam edin.

Yükün gerçekten nerede olduğuna bakın

top -b -n1 | head -20
iostat -x 1 3
free -h

Burada aradığınız üç işaret var:

• %iowait yüksekse disk bekleniyor demektir; sorun CPU değil depolamadır.
• swap kullanımı varsa RAM yetmiyordur ve her istek diske düşüyordur.
• Yük ortalaması çekirdek sayısının üzerindeyse gerçekten CPU sınırındasınızdır.

En sık karşılaştığımız gerçek sebep: veritabanı

Deneyimimizde yavaş sitelerin büyük çoğunluğunda sebep, indekslenmemiş sorgulardır. Sunucuyu ikiye katlamak, tam tablo taraması yapan bir sorguyu yalnızca iki kat hızlandırır; indeks eklemek aynı sorguyu yüz kat hızlandırabilir.

Yavaş sorgu kaydını açın ve bir gün boyunca toplanan kayıtlara bakın. Neredeyse her zaman birkaç sorgu toplam sürenin çoğunu tüketir.

Ne zaman gerçekten yükseltme gerekir

Şu üç koşul birlikte sağlanıyorsa yükseltme doğru karardır: yük ortalaması sürekli çekirdek sayısının üzerinde, swap aktif olarak kullanılıyor ve uygulama tarafında düzeltilecek belirgin bir sorgu kalmadı.

Aksi hâlde daha büyük bir sunucu, aynı sorunu daha pahalı biçimde yaşatır.