Performansa Giriş

Veritabanı performansı; veritabanı, ağlar, veritabanı sürücüsü ve EF Core gibi veri erişim katmanları gibi tüm bir bileşen yığınını kapsayan geniş ve karmaşık bir konudur. EF Core gibi üst düzey katmanlar ve O/RM'ler uygulama geliştirmeyi önemli ölçüde basitleştirip ve sürdürülebilirliği artırmakla birlikte bazen yürütülmekte olan SQL gibi performans açısından kritik iç ayrıntıları gizleyerek saydam olmaktan uzak olabilir. Bu bölümde EF Core ile iyi performans elde etme ve uygulama performansını düşürebilecek yaygın tuzaklardan kaçınmaya genel bir bakış sunmaya çalışılmıştır.

Performans sorunlarını belirleme ve ölçme, ölçme, ölçme

Performansta her zaman olduğu gibi, veriler bir sorun göstermeden önce aceleyle iyileştirmeye yönelmemek önemlidir; Donald Knuth'un bir keresinde dediği gibi "Vaktinden önce iyileştirme tüm kötülüklerin anasıdır." Performans tanılama bölümünde uygulamanızın veritabanı mantığında nerede zaman harcadığını anlamanın ve sorunlu alanları nasıl saptanacağının çeşitli yolları tartışılmaktadır. Yavaş bir sorgu tanımlandıktan sonra çözümler değerlendirilebilir: Veritabanınızda dizin mi eksik? Başka sorgulama desenlerini mi denemelisiniz?

Kodunuzu ve olası alternatifleri her zaman kendiniz karşılaştırın. Performans tanılama bölümünde BenchmarkDotNet ile örnek bir karşılaştırma bulunur. Bu karşılaştırmayı kendi karşılaştırmalarınız için şablon olarak kullanabilirsiniz. Genel amaçlı, herkese açık karşılaştırmaların kullanım örneğiniz için olduğu gibi geçerli olduğunu varsaymayın. Veritabanı gecikme süresi, sorgu karmaşıklığı ve tablolarınızdaki gerçek veri miktarları gibi çeşitli etkenlerin en iyi çözümü bulma üzerinde derin bir etkisi olabilir. Örneğin, birçok herkese açık karşılaştırmalar, veritabanında gecikme süresinin neredeyse sıfır olduğu ideal ağ koşullarında ve veritabanı tarafında neredeyse hiç işlem (veya disk G/Ç) gerektirmeyen son derece hafif sorgularla gerçekleştirilir. Bunlar farklı veri erişim katmanlarının çalışma zamanı ek yüklerini karşılaştırmak için değerli olsa da ortaya çıkardıkları farkların sıklıklar veritabanının gerçek işi gerçekleştirdiği ve veritabanı gecikme süresinin önemli bir performans faktörü olduğu gerçek bir uygulamada göz ardı edilebilir olduğu anlaşılır.

Veri erişim performansının yönleri

Genel veri erişim performansı aşağıdaki geniş kategorilere ayrılabilir:

• Salt veritabanı performansı. İlişkisel veritabanları ile EF, uygulamanın LINQ sorgularını veritabanı tarafından yürütülen SQL deyimlerine çevirir; bu SQL deyimlerinin kendileri aşağı yukarı verimli bir şekilde çalışabilir. Doğru yerde oluşturulan bir dizin, SQL performansında çok önemli bir fark oluşturabilir veya LINQ sorgunuzu yeniden yazmak EF'nin daha iyi bir SQL sorgusu oluşturmasını sağlayabilir.
• Ağ veri aktarımı. Her ağ sisteminde olduğu gibi hatlarda gidip gelen veri miktarını sınırlamak önemlidir. Bu, yalnızca gerçekten ihtiyacınız olacak verileri gönderip yüklediğinizden emin olmanın yanı sıra ilgili varlıkları yüklerken "kartezyen patlama" olarak adlandırılan etkiyi önlemeyi de kapsar.
• Ağ gidiş dönüşleri. Gidip gelen veri miktarı ve ağda gidiş geliş sayısının ötesinde, bir sorgunun veritabanında yürütülmesi için geçen süre, ağ paketlerinin uygulamanız ile veritabanınız arasında gidip gelme süresinin yanında hiç kalabilir. Gidiş dönüş ek yükü büyük ölçüde ortamınıza bağlıdır; veritabanı sunucunuz ne kadar uzaksa gecikme süresi de o kadar uzun, her gidiş dönüşün maliyeti de o kadar yüksek olur. Bulutun ortaya çıkmasıyla birlikte, uygulamalar veritabanından giderek daha da uzaklaşmakta ve çok fazla gidiş dönüş yapan "geveze" uygulamalar performans düşüşü göstermektedir. Bu nedenle uygulamanızın veritabanıyla tam olarak ne zaman bağlantı kurduğunu, kaç gidiş dönüş gerçekleştirdiğini ve bu sayının azaltılıp azaltılamayacağını anlamak önemlidir.
• EF çalışma zamanı ek yükü. Son olarak EF'nin kendisi veritabanı işlemlerine bir miktar çalışma zamanı ek yükü getirir: EF'nin sorgularınızı LINQ'ten SQL'e derlemesi gerekir (normalde yalnızca bir kez yapılmalıdır) ve değişiklik izleme biraz ek yük getirir (ancak devre dışı bırakılabilir). Uygulamada, veritabanında sorgu yürütme süresi ve ağ gecikme süresi toplam süreye hakim olduğundan, gerçek uygulamalar için EF ek yükü çoğu durumda göz ardı edilebilir, ancak seçeneklerinizin ne olduğunu ve bazı tuzaklardan nasıl kaçınılacağını anlamak önemlidir.

Arka planda neler olduğunu bilin

EF, SQL oluşturarak, sonuçları gerçekleştirerek ve diğer görevleri gerçekleştirerek geliştiricilerin iş mantığına odaklanmasına olanak tanır. Ancak her katman veya soyutlama gibi o da yürütülmekte olan gerçek SQL sorguları gibi arka planda olup bitenleri gizleme eğilimindedir. Performans, her uygulamanın kritik bir yönü olmayabilir, ancak olduğu uygulamalarda geliştiricinin EF'nin onun için ne yaptığını anlaması çok önemlidir: giden SQL sorgularını inceleme, N+1 sorununun oluşmadığından emin olmak için gidiş dönüşleri izleme vb.

Veritabanının dışında önbellek

Son olarak, bir veritabanıyla etkileşim kurmanın en verimli yolu, veritabanıyla hiç etkileşim kurmamaktır. Diğer bir deyişle, veritabanı erişimi uygulamanızda bir performans darboğazı olarak görünüyorsa, istekleri en aza indirmek için belirli sonuçları veritabanının dışında önbelleğe almak faydalı olabilir. Önbelleğe alma karmaşıklığı artırsa da ölçeklenebilir uygulamaların özellikle önemli bir parçasıdır: Artan yükün altından kalkmak için sunucu eklenerek uygulama katmanı kolayca ölçeklendirilebilirse de veritabanı katmanını ölçeklendirmek genellikle çok daha karmaşıktır.