High-Performance Queries with Entity Framework Core 10
N+1 problem'ini çözün, AsNoTracking kullanın ve raw SQL ile veri çekerek yüksek performanslı sorgulamalar yazın.
03.f796270b numaralı fikir
Production'da masum görünen bir refactor, cache stratejisini bozarak performansı ciddi şekilde düşürebilir. Her kod tekrarı kötü değildir; bazıları bilinçli optimizasyonun parçasıdır.
Bir sistemde "küçük bir temizlik" yapılıyordu.
Ama o küçük temizlik, production ortamında hiç beklemediğimiz bir problemi tetikledi.
API'de iki farklı endpoint vardı:
GET /products/99 → 8 ms
GET /products?id=99 → 340 ms
İkisi de aynı veriyi döndürüyordu.
Bir junior geliştirici doğal olarak şunu düşündü:
"Bunlar duplicate. Temizleyelim."
Mantıklıydı. Hatta ilk bakışta tam bir best practice gibi görünüyordu.
Refactor yapıldı.
İki endpoint tek endpoint altında birleştirildi.
Deploy sonrasında ilk metrikler gelmeye başladı.
Sistem artık daha "temiz" görünüyordu.
Ama kesinlikle daha hızlı değildi.
Sorun kodda değildi.
Sorun, yapılan varsayımdı.
İki endpoint aynı veriyi döndürmesine rağmen sistem onları farklı şekilde kullanıyordu.
Çünkü:
/products/99 ile /products?id=99 farklı cache entry'leri oluşturuyordu.Yani sistem aslında şunu yapıyordu:
Refactor sonrasında ise:
Biz yalnızca duplicate endpoint gördük.
Fakat sistem aslında farklı cache stratejileri kullanarak performans optimizasyonu yapıyordu.
Biz bunu fark etmeden kaldırmış olduk.
"Clean Code" her zaman doğru hedef olmayabilir.
Çünkü:
Kodun neden öyle yazıldığını anlamadan yapılan temizlik bazen faydadan çok zarar getirebilir.
Refactor öncesinde kendine şu soruları sormakta fayda var:
Bazen en temiz görünen kod, en doğru çalışan kod olmayabilir.