Optimizasyonun birinci kuralı: hiçbir şeye dokunmadan önce ölçün. Sorgu loglamayı ve dashboard isteğinin etrafına basit bir zamanlayıcı açtık. İlk sayı acımasızdı: 4,1 saniye. Bunun neredeyse tamamı tarayıcı değil, veritabanıydı.
1 — N+1 sorgu tuzağı
Dashboard şubeleri listeliyor ve her şube için bugünkü satışları ayrı bir sorguyla çekiyordu. 12 şubeyle bu 1 + 12 gidiş-dönüş demek. Bunu tek bir gruplu sorguya indirdik. Yalnızca bu değişiklik 4,1 saniyeyi 1,6 saniyeye düşürdü.
"N+1 yasaktır. İndeksler tahminle değil, ölçümle konur." — RESWONS DNA
2 — Eksik indeksler
Gruplu sorgu hâlâ satış tablosunun tamamını tarihe göre tarıyordu. (tenant_id, sale_date) üzerine bir bileşik indeks, tam taramayı bir aralık aramasına çevirdi. 1,6 saniye 950 milisaniyeye indi — ve veritabanı CPU grafiği düzleşti.
3 — Değişmeyeni önbelleğe almak
Dünün toplamları asla değişmez. Tamamlanmış günlerin özetlerini önbelleğe aldık ve yalnızca bugünün rakamlarını canlı hesapladık. Dashboard'un tekrar yüklemeleri artık çoğunlukla önbellekten okuyor ve tipik istekten 150 milisaniye daha kırpıyor.
4 — Frontend'in payı
Backend hızlanınca render görünür hâle geldi. Kritik olmayan scriptleri ertledik, ekranın altındaki grafikleri lazy-load yaptık ve yalnızca tek bir ekranda kullandığımız grafik kütüphanesini göndermeyi bıraktık. Orta seviye bir telefonda etkileşime hazır olma süresi 800 milisaniyenin altına düştü.
Sonuç
- Dashboard yüklemesi: 4,1 sn → 800 ms (≈ %80 daha hızlı)
- Yükleme başına veritabanı sorgusu: 13 → 2
- Gönderilen JavaScript: o ekranda ~%40 azaldı
Çıkarım
Performans nadiren tek bir kahramanca düzeltmedir; ölçerek bulunan bir avuç gösterişsiz düzeltmedir. N+1'leri öldürün, kanıta göre indeksleyin, değişmeyeni önbelleğe alın ve tarayıcıya daha az gönderin. Bunu yapın; "yavaş" genellikle çok düzeltilebilir çıkar.
Bu tercihlerin arkasındaki prensipler DNA sayfamızda.