Performans Testiyle Sorgu İyileştirmesini Ölçmek
CQRS ayrımından sonraki yüzde 40'lık kazancı öncesi-sonrası ölçümle doğruladım.
Mert Celal Yılmaz · Full Stack Developer · Güncellendi:
100 kayıtla sorunsuz çalışan bir filtreleme ekranı, sayı 10 bine çıkınca birden yavaşlayabilir. Performans testi tam olarak bunu ölçmek için var: kodun doğru sonucu verip vermediğini değil, bu sonucu ne kadar sürede ve ne kadar kaynakla ürettiğini. Gerçek kullanım senaryosuna yakın veri hacmiyle sorguları çalıştırıp süreyi, sorgu sayısını, bellek kullanımını ölçüyorsun.
Bir apartman yönetim sisteminin ilk versiyonunda okuma ve yazma sorguları aynı model üzerinden yürüyordu; CQRS yaklaşımıyla bu ikisini ayırdım, yani okuma tarafını yazma tarafından bağımsız, kendi ihtiyacına göre optimize edilmiş sorgularla besledim. Bu ayrımdan sonra sorgu performansında ölçülen iyileşme yüzde 40'a ulaştı.
Bu sayı havadan gelmedi, öncesi ve sonrası aynı veri seti ve aynı senaryolarla test edilerek çıktı. Performans iyileştirmesini 'daha hızlı hissettiriyor' değil, ölçülebilir bir farkla konuşmak hem kendi kararını doğrulamak hem de ekibe anlatmak için işe yarıyor. Ölçmeden yapılan optimizasyon çoğu zaman tahmin oluyor, bu yüzden önce ölçüyorum.
%40'lık kazancın büyük kısmı CQRS'in kendisinden değil, ayrımdan sonra read tarafına uygulanan somut değişikliklerden geldi — sorgu tarafı AsNoTracking ile çalışmaya başladı, yani EF Core artık sadece ekranda listelenecek satırlar için değişiklik takibi belleği ayırmıyor, üstelik filtreleme sorguları tüm entity yerine sadece liste ekranında gösterilen kolonları çeken projeksiyonlara indirgendi. Taşınan veri miktarını ve tracking maliyetini aynı anda düşürmek, ölçülen kazancın büyük kısmını açıklıyor.
CQRS'i sadece yapısal bir ayrım olarak uygulayıp read tarafına özel bir optimizasyon yapmazsanız performans kazancı kendiliğinden gelmiyor — ayrım size sadece read ve write'ı birbirinden bağımsız optimize edebileceğiniz bir sınır veriyor, kazanç o sınırın içine ne koyduğunuza bağlı. Ayrıca testi üretimdekine yakın veri hacmiyle koşmak şart; birkaç yüz satırlık bir test veritabanında görünmeyen maliyetler ancak gerçek hacimde belirginleşiyor. Solo olarak geliştirdiğim bulut tabanlı doküman yönetim sisteminde 10 binden fazla doküman için filtreleme ve erişim altyapısını tasarlarken de belirleyici olan buydu.