Site Yavaşladıysa Ne Yapmalı? Sunucu Kaynaklı mı?

Site Yavaşladıysa Ne Yapmalı? Sunucu Kaynaklı mı?

Bir site yavaşladığında refleks hep aynıdır: “Tema ağır”, “Eklenti şişirdi”, “WordPress zaten böyle”… Oysa çoğu zaman gerçek problem, görünenden daha aşağıdadır: sunucu performansı dalgalanıyordur, kaynaklar anlık tıkanıyordur ya da altyapı büyümeyi artık kaldıramıyordur. Üstelik bu sadece kullanıcı deneyimi meselesi değil; aynı işi daha uzun sürede yapmak, daha çok kaynak tüketmek demektir. Temiz teknoloji perspektifinden bakınca yavaşlık, gereksiz CPU döngüsü, gereksiz disk okuma-yazma ve daha fazla enerji tüketimi anlamına gelir. Bu rehberde “hissedilen yavaşlığı” ölçülebilir sinyallere çevirip, sorunun tema/eklenti mi yoksa sunucu mu olduğunu netleştireceğiz. Sonunda da “ne zaman VDS’e geçmeliyim?” sorusunu tartışmadan, somut işaretlerle yanıtlayacağız.

Yavaşlığın 2 hızlı göstergesi: TTFB ve hata oranı

Yavaşlığı anlamanın en hızlı yolu, sunucu performansı tarafını doğrudan işaret eden iki metriğe bakmaktır: TTFB (Time To First Byte) ve hata oranı. TTFB, tarayıcının isteği gönderdiği andan sunucudan ilk baytı aldığı ana kadar geçen süredir. Yani “sayfa ağır” demeden önce, “sunucu ilk yanıtı ne kadar hızlı veriyor?” sorusunun cevabıdır. TTFB’nin yükselmesi; çoğu zaman PHP/uygulama süresi, veritabanı beklemesi, disk gecikmesi veya ağ tarafında bir kuyruk oluştuğunu gösterir. Kullanıcı “site açılmıyor” derken, aslında sayfa içerikleri henüz başlamadan kaybedilen süre büyümüştür. İkinci gösterge hata oranıdır. Hata derken yalnızca 500’leri kastetmiyoruz; timeout, gateway hataları (502/504), “connection reset” gibi aralıklı kopmalar da çok değerlidir. Çünkü yavaşlık bazen “sürekli yavaş” değil, “pik saatlerde aniden çöküyor” şeklinde yaşanır. Bu tip dalgalanmalar, genellikle kaynak doygunluğunun (CPU/RAM/IO) veya sınırlayıcıların (process limit, I/O limit, connection limit) işaretidir. Pratik okuma şu:

• TTFB yükseliyor + hata artıyorsa, problem büyük ihtimalle uygulamanın arkasındaki kaynaklara dayanır.
• TTFB normal ama sayfa yine geç tamamlanıyorsa, ön yüz (tema, görseller, JS) veya üçüncü parti servisler (CDN, font, API) daha olasıdır.

Tema/eklenti mi sunucu mu? Ayrımı nasıl yaparsın?

Sorunu doğru yere koymak, gereksiz optimizasyon döngüsünü bitirir. Tema/eklenti ve sunucu ayrımını yapmak için “aynı içeriği farklı yüklerde” test etmek gerekir; çünkü tema/eklenti sorunları çoğu zaman her koşulda benzer davranır, sunucu kaynak sorunları ise yükle birlikte büyür. İlk adım: statik bir uç nokta ile dinamik bir sayfayı kıyaslayın. Örneğin önbellekten servis edilebilen bir sayfa ile giriş gerektiren (panel, sepet, arama) bir sayfa aynı hızda bozulmuyorsa, işin içinde PHP/veritabanı döngüsü vardır. Tema tarafı ağır olsa bile, “ilk yanıt”ın (TTFB) bu kadar oynaması genellikle sunucu/arka uç işaretidir. İkinci adım: Eklentileri kapatıp açmak yerine, günlük yük altında ölçüm alın. Çünkü tek kullanıcıyla yapılan test “iyi” görünür; ama 20–50 eşzamanlı istek geldiğinde tablo değişir. Burada amaç bir laboratuvar testi değil; sizin gerçek trafiğinize benzeyen bir senaryoda, yanıt sürelerinin kuyruğa girip girmediğini görmek. Üçüncü adım: kaynak grafikleriyle “hissedilen yavaşlığı” aynı zaman çizgisine koyun. CPU %20’de gezerken yavaşlık artıyorsa, “CPU yetmiyor” tezi zayıflar; ama disk beklemesi veya veritabanı kilitleri devreye girmiş olabilir. Tam tersi; CPU %90+’a vurup yanıt süreleri uzuyorsa, uygulama katmanı CPU’ya yükleniyordur (ağır sorgu, şişkin PHP işlemi, yoğun şablon render, sık cache miss). Bu ayrımı doğru yaptığınızda, “tema değiştir” gibi kökten ama gereksiz hamleler yerine, asıl boğazı hedefleyen bir iyileştirme planı çıkar.

Veritabanı şişmesi: yavaş sorgu mantığı (paragraf)

Veritabanı büyüdükçe site yavaşlar demek eksik kalır; kritik olan hangi sorguların neden yavaşladığıdır. Yavaş sorgu mantığı basittir: Sorgu, indeksli bir alanı kullanmıyorsa veya filtreleme/sıralama büyük bir tabloyu tarıyorsa, yük altında süre katlanır. Özellikle WordPress ekosisteminde, ürün/filtreleme, arama, raporlama, log tutma ve bazı “istatistik” eklentileri, tabloyu büyütürken sorgu desenini de ağırlaştırır. Sonuç: Normalde 80 ms süren bir sorgu, yoğunlukta 800 ms olur; bu da sayfa yanıtını domino gibi büyütür. Çözüm yaklaşımı “veritabanını küçültmek” değil; yavaş sorguyu tespit edip indeks/temizlik/önbellek stratejisiyle düzeltmektir. Burada amaç, aynı işi daha az işlemle yaparak hem sunucu performansı kazanmak hem de gereksiz kaynak tüketimini azaltmaktır.

Disk IO beklemesi: “CPU boş ama site yavaş” senaryosu

En kafa karıştıran durum şudur: CPU düşük görünür, RAM fena değildir, ama site yavaştır. Bu senaryoda sıkça suçlu, Disk I/O beklemesidir. Disk I/O beklemesi olduğunda işlemci aslında “boş” değildir; sadece işini bitirecek veriyi diskten bekliyordur. Bu da dışarıdan “CPU %15, niye yavaş?” gibi görünür. Özellikle yoğun log yazımı, çok sayıda küçük dosya okuma (tema dosyaları, görseller, cache dosyaları), eşzamanlı yedekleme veya virüs taraması gibi işler disk kuyruğunu şişirebilir. Veritabanı da disk üzerinde çalıştığı için, bir yavaş disk her şeyi zincirleme etkiler. Bunu pratikte nasıl anlarsınız? Yük anlarında sayfa açılışının “ilk yanıtı” gecikir; admin paneli ağırlaşır; bazen görsel yükleme bile takılır. Özellikle paylaşımlı ortamlarda veya I/O limitli planlarda bu belirti çok nettir. İyi bir vds sunucu altyapısında NVMe diskler ve doğru I/O planlaması, bu tür “görünmez beklemeleri” ciddi ölçüde azaltır.

VDS’e geçiş eşiği (3 belirtiyle net karar)

“VDS’e geçeyim mi?” sorusu, çoğu kişi için muğlaktır. Oysa üç belirti birlikte geliyorsa karar nettir; çünkü konu konfor değil, sürdürülebilir çalışmadır:

1. Trafik artınca yanıt süreleri lineer değil katlanarak uzuyorsa: Bu, kuyruğa girme belirtisidir. İstekler sıraya dizilir, her yeni istek bir öncekini bekler. Bu noktada optimize edilecek şeyler vardır ama altyapı da sınırda demektir.
2. Aralıklı 502/504, timeout veya “resource limit” benzeri hatalar görünüyorsa: Hata “nadiren” bile olsa önemlidir; çünkü kullanıcı o anı yaşar ve kayıp o anda olur. Bu, kaynakların pikte doygunluğa ulaştığını gösterir.
3. Uygulama tarafı iyileştirildiği hâlde TTFB hâlâ yüksekse: Görselleri optimize ettiniz, cache’i iyileştirdiniz, eklentileri sadeleştirdiniz; ama ilk yanıt gecikmesi düşmüyorsa, sunucu performansı tarafında daha sağlam kaynak izolasyonu ve daha hızlı disk/ağ gerekebilir.

Bu eşikte VDS’e geçiş, “daha hızlı olsun” isteğinden çok “hızın stabil kalması” hedefidir. Stabilite; daha az tekrar deneme, daha az boşa işlem, dolayısıyla daha verimli kaynak kullanımı demektir.

VDS seçerken 5 pratik kriter (abartısız)

Bir ölçeklenebilir VDS sunucu seçerken liste uzatılabilir; ama karar vermeyi gerçekten etkileyen 5 pratik kriter yeterlidir:

• NVMe depolama ve gerçek I/O kapasitesi: Kağıt üstünde GB değil, yük altında gecikmeyi belirleyen disk altyapısıdır.
• CPU mimarisi ve tek çekirdek performansı: Pek çok web işi hâlâ tek çekirdekte patlar; “çekirdek sayısı” kadar “çekirdek kalitesi” de önemlidir.
• RAM yeterliliği ve cache alanı: Veritabanı ve uygulama cache’i RAM’de rahat ederse disk baskısı azalır.
• Ağ kalitesi ve gecikme: Sadece Mbps değil; rota/peering ve paket kaybı olmaması kullanıcı deneyimini belirler.
• Kolay ölçeklenebilirlik ve izleme: Kaynağı artırmak zor ve kesintiliyse büyüme sancılı olur; izleme yoksa sorunlar geç fark edilir.

Bu kriterler; “en pahalıyı al” değil, ihtiyaca göre “boğazı rahatlat” yaklaşımıdır.

Geçiş ve test: “önce doğrula sonra yönlendir” planı

Geçişte en sık yapılan hata şudur: Önce DNS’i çevirip sonra sorun aramak. Doğru sıra tersidir: Önce doğrula, sonra yönlendir. Önce doğrulama aşamasında; yeni sunucuda aynı sürümler, aynı ayarlar, aynı veritabanı ile siteyi ayağa kaldırırsınız. Ardından gerçekçi test gelir: kritik sayfalar, giriş akışı, ödeme/iletişim formları, arama, admin paneli ve cron işleri… Bu testlerde yalnız “açılıyor mu?” değil, “yük altında tutarlı mı?” sorusuna yanıt aranır. TTFB ve hata oranı burada tekrar devreye girer; çünkü geçişin başarısı, hızın yalnızca anlık değil sürdürülebilir şekilde iyileşmesidir. Yönlendirme (DNS) aşamasına geldiğinizde hedef; minimum TTL ile kontrollü geçiş, ardından log/izleme ile ilk 24–48 saati yakından takip etmektir. Eğer bir şey ters giderse geri dönüş planı net olmalıdır: Eski sunucu kapatılmadan önce, geri dönüş adımı tek hamlede uygulanabilmelidir. Bu yaklaşım, hem operasyonel riski azaltır hem de “geçtik ama neden hâlâ yavaş?” sorusunu en baştan engeller. Sitenizde yavaşlığın kaynağını netleştirdikten sonra, doğru altyapı seçimi işinizi kolaylaştırır. İhtiyacınıza göre web hosting çözümleri için ana sayfaya göz atabilirsiniz: web hosting çözümleri Kaynak izolasyonu ve büyüme için daha kontrollü bir yapı arıyorsanız, ölçeklenebilir VDS sunucu sayfası iyi bir başlangıç noktasıdır.