Sayfa açılışları uzuyor, yönetim paneli bile gecikiyor, müşteri “site çöktü mü?” diye yazıyor… Çoğu zaman ilk şüpheli DDoS olur. Oysa pratikte site yavaşlama nedenleri listesinin başında, gürültüsüz ama yıpratıcı bir şey var: bot trafiği. Üstelik bu yük, “tek bir saldırı anı” gibi görünmeden, gün boyu birikerek CPU’yu, veritabanını ve disk IO’yu boğabiliyor. Eğer altyapıyı baştan doğru kurup temel kontrolleri düzenli yaparsanız, bu senaryoların büyük kısmı daha büyümeden söner. Başlangıç için performans odaklı hosting yaklaşımı, sadece “hızlı sunucu” değil; izleme, sınır koyma ve hızlı toparlama disiplinidir.
Aşağıdaki başlıklarda “DDoS olmadan da neden yavaşlıyor?” sorusunu, log’dan veritabanına, IO wait’ten cron gecikmesine kadar net bir omurgayla ele alıyorum. Hedef: botların sitenizi yavaşlatmasını görünür kılmak ve kontrolü geri almak.
DDoS olmadan da site neden yavaşlar?
DDoS deyince akla genelde devasa trafik ve bariz kesinti geliyor. Bot trafiği ise daha sinsidir: bazen saniyede birkaç istekle başlar, “normal kullanıcı” gibi gezinen user-agent’larla dolaşır, cache’e takılmamak için dinamik URL’leri kurcalar. Sonuçta sitenin “ayakta” görünmesine rağmen hissettirilen performans düşer. Kullanıcı tarafında bu, “ilk byte geç geliyor”, “arama yavaş”, “sepet geç açılıyor”, “panel kilitleniyor” diye anlatılır.
Buradaki kritik nokta şu: site yavaşlama nedenleri çoğu zaman tek bir bileşen değildir; zincirleme etki olur. Bir bot, pahalı bir arama sayfasını sürekli tetikler. O sayfa veritabanında ağır sorgu çalıştırır. Sorgu kilitlenir veya uzun sürer. PHP worker’ları bekler. Worker’lar dolunca yeni istekler kuyruğa girer. Kuyruk büyüyünce “her şey” yavaşlar. Bu süreçte bant genişliğiniz hâlâ boş olabilir; ama CPU, RAM, veritabanı ve disk beklemeleri “içeride” yanar.
DDoS olmayan yavaşlamalarda sık gördüğüm tetikleyiciler: tarayıcı botları (scraper), fiyat/ürün çekmeye çalışan otomasyonlar, agresif arama motoru botları, kırılgan endpoint’leri deneyen güvenlik taramaları, WP xmlrpc / login denemeleri, /wp-json veya özel API uçlarının aşırı çağrılması. Bir de “iyi niyetli” ama yanlış kurgulanmış entegrasyonlar var: dış servis her 10 saniyede bir kontrol atıyor, cache’i deliyor, siteyi 24 saat dürtüyor.
Bot trafiği nasıl anlaşılır? (log/analytics ipuçları)
Botu yakalamak için önce “hissiyatı” veriye çevirmeniz gerekir. Bir gecikme şikâyeti geldiğinde, tek bir ekran görüntüsü yerine üç yerden doğrulama yapın: erişim log’u, uygulama/analytics ve kaynak kullanımı.
Erişim log’larında bot kokusu genelde aynı kalıplarla çıkar: çok yüksek istek sayısı, kısa aralık, aynı IP bloğu, sıra dışı URL’ler, anormal parametre çeşitliliği. “Gerçek kullanıcı” çoğunlukla birkaç sayfa gezer; bot ise sistematik tarar. Özellikle şu sinyaller güçlüdür:
- Tek bir IP’den dakikalar içinde yüzlerce farklı URL isteği (kategori, filtre, arama, sayfalama).
- Aynı sayfaya “cache kırmak” için sürekli farklı query string eklemek (?utm=…, ?v=…, rastgele parametreler).
- Garip user-agent’lar (boş, aşırı uzun, “python-requests”, “curl”, “HeadlessChrome” gibi).
- Kısa sürede çok sayıda 404 (admin yolları, eski tema dosyaları, bilinen açık yolları).
- POST denemeleri (login, xmlrpc, API) ve yüksek 401/403/429 dalgaları.
Analytics tarafında da ipucu var ama tek başına yetmez. Botların bir kısmı JS çalıştırmadığı için klasik analytics’e düşmez; ama “sayfa görüntülenme düşmedi, site yavaş” çelişkisi zaten şüpheyi artırır. Öte yandan Cloudflare/benzeri bir katman kullanıyorsanız, “top threats”, “top countries”, “top paths” gibi raporlarda anormal yoğunlaşmaları görürsünüz.
Hızlı pratik: yavaşlık anında en çok istek alan URL’leri çıkarın. Eğer listenin tepesinde giriş sayfası değil de arama, filtre, API veya admin benzeri uçlar varsa, büyük ihtimalle bot trafiği bir şeyi deliyordur. Bu noktada mesele “trafik çok” değil; “trafik pahalı yerlere vuruyor” meselesidir.
Rate-limit ve temel koruma mantığı
Botla mücadelede en etkili ilk hamle, “herkese her şeyi sınırsız verme” alışkanlığını bırakmaktır. Rate-limit mantığı basittir: belirli bir süre içinde aynı kaynaktan gelen istek sayısını sınırla; aşana ya gecikme uygula ya da 429 ile geri çevir. Bu, DDoS savunması gibi ağır bir senaryo beklemeden, günlük bot basıncını ciddi biçimde azaltır.
Burada iki denge kritik: gerçek kullanıcıyı üzmeden botu yavaşlatmak ve dinamik sayfaları korurken statik içeriği serbest bırakmak. Örneğin ana sayfa ve görseller cache’ten akabilir; ama arama sayfası, filtreleme uçları, login endpoint’i, xmlrpc, API route’ları daha sıkı kurallara girmelidir.
Koruma katmanları üç seviyede düşünülür:
Birincisi, CDN/WAF seviyesinde basit kurallar: şüpheli user-agent, belirli ülke/ASN yoğunluğu, anormal istek oranı, belirli path’lere eşik. Bu katman, sunucuya daha gelmeden gürültüyü keser.
İkincisi, web sunucusu seviyesinde limitler: aynı IP’ye bağlantı/istek sınırı, belirli path’lere limit, agresif taramayı yavaşlatma. Bu katman, uygulamayı korur.
Üçüncüsü, uygulama seviyesinde: pahalı sorgulara cache, aramaya debounce/limit, login denemelerine throttle, bot tespitinde challenge (ör. captcha) gibi çözümler.
En büyük hata, “tamam rate-limit koyduk” deyip her şeyi tek kurala bağlamak. Botlar bazen dağıtık gelir; bazen de tek IP değil, bir IP havuzuyla dolaşır. O yüzden limitleri “kritik endpoint” bazlı kurgulamak, genel limitten daha işe yarar.
Veritabanı kilitleri ve cron gecikmesi
Bir sitenin yavaşlamasında veritabanı kilitleri çoğu zaman görünmez kahramandır. Her şey “çalışıyor” gibi durur ama bazı sorgular birbirini bekler. Botlar bu beklemeyi büyütür; çünkü aynı tabloya aynı anda daha fazla okuma/yazma bindirir. Özellikle e-ticaret, üyelik, sepet, stok, fiyat güncelleme gibi alanlarda kilit beklemeleri hızla hissedilir.
Kilidin tipik senaryosu şudur: cron bir iş başlatır (sipariş senkronu, mail kuyruğu, kampanya güncellemesi). Aynı anda botlar yoğun şekilde arama/ürün çekme yapar. Bazı tablolar hem cron tarafından yazılır, hem bot tarafından okunur. Okuma-yazma çakışınca “bekleme” oluşur. Bu bekleme PHP tarafında “sayfa açılmıyor” diye görünür; aslında sayfa veritabanı cevabını bekliyordur.
Cron gecikmesi de ayrı bir çarpan. Cron işleri zamanında çalışmayınca kuyruk birikir; birikmiş işleri cron yakalamaya çalışırken daha çok kaynak tüketir; kaynak tüketimi artınca site daha da yavaşlar. Özellikle WordPress tarafında wp-cron’un trafikle tetiklenmesi, bot basıncında işleri iyice karıştırabilir: bot geldikçe cron tetiklenir, cron çalıştıkça site ağırlaşır, ağırlaştıkça gerçek kullanıcı daha çok bekler.
Burada iyi pratik: cron’ları “rastgele trafik” yerine sistem cron’una bağlamak, ağır işleri parçalamak, aynı anda çalışan job sayısını kontrol etmek ve veritabanında ağır sorguları tespit edip optimize etmek. Yavaşlık şikâyetinde “CPU niye yüksek?” kadar “veritabanı neyi bekliyor?” sorusunu da sormak gerekir. Çünkü site yavaşlama nedenleri arasında kilit beklemeleri en çok gözden kaçan ama en çok can yakanlardan biridir.
Disk IO ve “bekleme” sorunu (IO wait)
CPU kullanımınız çok yüksek olmayabilir; RAM de boş görünebilir; ama site yine de sürünebilir. Bu durumda sahneye çoğu kişinin sevmediği metrik çıkar: IO wait. Kısaca, işlemcinin “iş yapamadığı”, çünkü diskten veri beklediği zaman dilimi. IO wait yükseldiğinde, web istekleri yanıtı bekler, veritabanı yavaşlar, cache yazamaz, log büyür, her şey zincirleme ağırlaşır.
Bot trafiği IO’yu nasıl artırır? Çok basit: cache’i delip dinamik içerik isteyerek daha fazla disk okuma/yazma yaptırır. Özellikle büyük log yazımı, session dosyaları, tmp dosyaları, görsel manipülasyonları, arama indeksleri, eklenti log’ları ve veritabanı dosyalarının yoğun erişimi IO’yu şişirir. Üstelik bu şişme “bir anda” değil, kademeli olur; bu yüzden fark etmek geç kalabilir.
IO tarafında en kritik yanlış anlama: “SSD var, sorun olmaz.” SSD tek başına yeterli değil; NVMe/IOPS kapasitesi, sanallaştırma katmanı, disk paylaşımı, dosya sistemi ayarları ve yazma yoğunluğu birlikte belirler. Paylaşımlı altyapılarda komşu yükü IO’yu etkileyebilir. Bu yüzden performans hassas projelerde vds sunucu tercihinin en net artılarından biri, disk ve IO davranışının daha öngörülebilir olmasıdır.
IO wait’i “hissetmeden” yakalamanın yolu düzenli izleme ve alarmdır. Bir yavaşlık olayında, CPU grafiğine bakıp “normal” deyip geçmek kolaydır; oysa IO wait grafiği yükseliyorsa, şişe boynu disktir ve çözümünüz de ona göre şekillenmelidir.
Trafik piklerinde stabilite: VDS’in rolü
Trafik pikleri her zaman kötü haber değildir; bazen kampanya tutar, bazen içerik viral olur, bazen arama motoru sizi iyi bir sıraya taşır. Kötü olan, o pikte sitenin “dağılmasıdır”. Bot trafiği de çoğu zaman tam bu anları sever: yükselen görünürlükle birlikte tarama baskısı artar, otomasyonlar devreye girer, kırılgan endpoint’ler daha çok dürtülür. İşte burada vds sunucu yaklaşımı “sadece daha güçlü makine” değil, daha stabil bir oyun alanı sunar.
VDS’in rolünü üç başlıkta düşünün:
Kaynak izolasyonu: Paylaşımlı ortamda bir anlık yoğunluk, komşu sitelerin kaynak tüketimiyle birleşince çöküşü hızlandırır. VDS’te CPU/RAM/IO limitleri daha nettir; bu, pik anında davranışı daha tahmin edilebilir yapar.
Ayarlanabilir koruma: Rate-limit, WAF, cache, PHP worker sayısı, veritabanı konfigürasyonu gibi ince ayarları daha esnek yönetirsiniz. Bot trafiği dalgasında “bir kural ekleyip hemen rahatlamak” çoğu zaman bu esneklikle mümkün olur.
Ölçeklenebilir toparlama: Kriz anında kaynak artırma, ayrı veritabanı katmanı, ayrı cache katmanı, log’ları başka diske alma gibi seçenekler daha kolay devreye girer. Bu da “yavaşladı, günlerce süründük” yerine “yakalandı, düzeltildi, stabilize oldu” çizgisini mümkün kılar.
Bu bölümde derli toplu seçenek görmek isterseniz, performans için VDS seçenekleri sayfası tam olarak bu “pik anında stabil kalma” ihtiyacına göre konumlanır. Sihir değil; ama bot basıncı, IO wait ve veritabanı kilidi gibi sorunları yönetilebilir hâle getiren doğru altyapı zemini.
Hızlı toparlama: 5 dakikalık kontrol listesi
Yavaşlık başladığında, “panik” yerine aynı sırayla ilerleyen bir refleks kazanmak, gerçek çözümü hızlandırır. Aşağıdaki adımlar “kök neden analizi”nin tamamı değil; ama bot kaynaklı site yavaşlama nedenleri için en hızlı eleme setidir. Her biri 30–60 saniyede fikir verir:
- En çok vurulan URL’yi bulun. O an en fazla istek alan path hangisi? Arama mı, login mi, API mı? “Pahalı endpoint” yakalarsanız doğru yerden başlarsınız.
- Status code dağılımına bakın. 404/401/403/429 artışı var mı? 429 görüyorsanız limit çalışıyor demektir; 404 patlıyorsa tarama var demektir.
- Aynı IP/ASN yoğunluğu var mı? Tek IP mi boğuyor, yoksa bir havuz mu var? Tek IP ise hızlı blok/limit; havuz ise path bazlı kural daha mantıklı.
- Veritabanı bekliyor mu? Sayfa “açılmıyor” gibi ama aslında sorgu bekliyor olabilir. Lock/bekleme sinyali varsa önce orayı rahatlatın.
- IO wait yükseldi mi? CPU normal ama IO wait yüksekse, mesele disktir. Log yazımı, yoğun görsel işlemi, veritabanı dosyası şişmesi gibi sebepleri düşünün.
- Cron kuyruğu birikti mi? Zamanında çalışmayan işler birikmişse, toparlama sırasında “her şeyi aynı anda koşturmayın”; işleri parçalayın, eşzamanlılığı azaltın.
- Cache’i doğrulayın. Botlar cache’i deliyorsa “hit rate” düşer. Cache politikası ve bypass kuralları kontrol edilmeden performans düzelmez.
- Geçici koruma ekleyin, sonra kalıcılaştırın. İlk etapta şüpheli path’e rate-limit/challenge ekleyin; sakinleşince log’dan öğrenip kalıcı kuralı yazın.
Bu kontrol setini her olayda uyguladığınızda, “vds sunucu mu yetmedi?” tartışması da daha netleşir. Bazen kaynak gerçekten yetmiyordur; bazen kaynak yeterlidir ama botlar pahalı endpoint’leri hedefliyordur. İkisini ayırmak, hem maliyeti hem de müdahale süresini ciddi biçimde iyileştirir.
Bot trafiğiyle mücadele, bir defalık “engelle” işi değil; ölç, sınırla, optimize et ve tekrar ölç döngüsüdür. Eğer doğru sinyalleri izlerseniz, vds sunucu gibi daha stabil bir zeminde, en sık görülen site yavaşlama nedenleri çok daha erken yakalanır ve “site boğuldu” noktasına gelmeden çözülür.
