PerformansLa İlgili Önemli Noktalar (Entity Framework)

  • Makale

Bu konu, ADO.NET Entity Framework'ün performans özelliklerini açıklar ve Entity Framework uygulamalarının performansını geliştirmeye yardımcı olmak için bazı önemli noktalar sağlar.

Sorgu Yürütme Aşamaları

Entity Framework'teki sorguların performansını daha iyi anlamak için, bir sorgu kavramsal modelde yürütür ve verileri nesne olarak döndürürse gerçekleşen işlemleri anlamak yararlı olur. Aşağıdaki tabloda bu işlem serisi açıklanmaktadır.

İşlem Göreli Maliyet Sıklık Açıklamalar
Meta verileri yükleme Orta Her uygulama etki alanına bir kez. Entity Framework tarafından kullanılan model ve eşleme meta verileri içine MetadataWorkspaceyüklenir. Bu meta veriler genel olarak önbelleğe alınır ve aynı uygulama etki alanındaki diğer örnekleri ObjectContext tarafından kullanılabilir.
Veritabanı bağlantısını açma Orta1 Gerektiği gibi. Veritabanına açık bir bağlantı değerli bir kaynak tükettiğinden, Entity Framework yalnızca gerektiğinde veritabanı bağlantısını açar ve kapatır. Ayrıca bağlantıyı açıkça açabilirsiniz. Daha fazla bilgi için bkz. Bağlan yonları ve İşlemleri Yönetme.
Görünüm oluşturma Yüksek Her uygulama etki alanına bir kez. (Önceden oluşturulabilir.) Entity Framework'ün kavramsal bir modele göre sorgu yürütebilmesi veya veri kaynağındaki değişiklikleri kaydedebilmesi için önce veritabanına erişmek için bir dizi yerel sorgu görünümü oluşturması gerekir. Bu görünümleri oluşturmanın yüksek maliyeti nedeniyle, görünümleri önceden oluşturabilir ve tasarım zamanında projeye ekleyebilirsiniz. Daha fazla bilgi için bkz . Nasıl yapılır: Sorgu Performansını Geliştirmek için Görünümleri Önceden Oluşturma.
Sorgu hazırlanıyor Orta2 Her benzersiz sorgu için bir kez. Sorgu komutunu oluşturma, model ve eşleme meta verilerini temel alan bir komut ağacı oluşturma ve döndürülen verilerin şeklini tanımlama maliyetlerini içerir. Artık hem Entity SQL sorgu komutları hem de LINQ sorguları önbelleğe alındığından, aynı sorgunun daha sonra yürütülmesi daha az zaman alır. Daha sonraki yürütmelerde bu maliyeti azaltmak için derlenmiş LINQ sorgularını kullanmaya devam edebilirsiniz ve derlenmiş sorgular otomatik olarak önbelleğe alınan LINQ sorgularından daha verimli olabilir. Daha fazla bilgi için bkz . Derlenmiş Sorgular (LINQ to Entities). LINQ sorgu yürütmesi hakkında genel bilgi için bkz . LINQ to Entities. Not: işleci bellek içi koleksiyonlara uygulayan Enumerable.Contains LINQ to Entities sorguları otomatik olarak önbelleğe alınmaz. Ayrıca derlenmiş LINQ sorgularında bellek içi koleksiyonların parametreleştirilmesine izin verilmez.
Sorguyu yürütme Düşük2 Her sorgu için bir kez. ADO.NET veri sağlayıcısını kullanarak veri kaynağına karşı komutunu yürütmenin maliyeti. Veri kaynaklarının çoğu sorgu planlarını önbelleğe aldıklarından, aynı sorgunun daha sonra yürütülmesi daha da kısa sürebilir.
Türleri yükleme ve doğrulama Düşük3 Her ObjectContext örnek için bir kez. Türler, kavramsal modelin tanımladığı türlere göre yüklenir ve doğrulanır.
İzleme Düşük3 Sorgu döndürdüğü her nesne için bir kez. 4 Sorgu birleştirme seçeneğini kullanıyorsa NoTracking , bu aşama performansı etkilemez.

Sorgu , PreserveChangesveya OverwriteChanges birleştirme seçeneğini kullanıyorsaAppendOnly, sorgu sonuçları içinde ObjectStateManagerizlenir. Sorgunun EntityKey döndürdüğü her izlenen nesne için bir oluşturulur ve içinde ObjectStateManagerbir ObjectStateEntry oluşturmak için kullanılır. için EntityKeymevcut ObjectStateEntry bir nesne bulunabiliyorsa, var olan nesne döndürülür. PreserveChangesOverwriteChanges veya seçeneği kullanılırsa, nesne döndürülmeden önce güncelleştirilir.

Daha fazla bilgi için bkz. Kimlik Çözümlemesi, Durum Yönetimi ve Değişiklik İzleme.
Nesneleri gerçekleştirme Orta3 Sorgu döndürdüğü her nesne için bir kez. 4 Döndürülen DbDataReader nesneyi okuma ve nesneleri oluşturma ve sınıfın her örneğindeki DbDataRecord değerleri temel alan özellik değerlerini ayarlama işlemi. nesnesi içinde ObjectContext zaten varsa ve sorgu veya PreserveChanges birleştirme seçeneklerini kullanıyorsaAppendOnly, bu aşama performansı etkilemez. Daha fazla bilgi için bkz. Kimlik Çözümlemesi, Durum Yönetimi ve Değişiklik İzleme.

1 Veri kaynağı sağlayıcısı bağlantı havuzu uyguladığında, bağlantı açma maliyeti havuza dağıtılır. SQL Server için .NET Sağlayıcısı bağlantı havuzunu destekler.

2 Artan sorgu karmaşıklığı ile maliyet artışı.

3 Toplam maliyet, sorgu tarafından döndürülen nesne sayısıyla orantılı olarak artar.

4 Bu ek yük EntityClient sorguları için gerekli değildir çünkü EntityClient sorguları nesneler yerine bir EntityDataReader döndürür. Daha fazla bilgi için bkz . Entity Framework için EntityClient Sağlayıcısı.

Ek Dikkat Edilmesi Gerekenler

Entity Framework uygulamalarının performansını etkileyebilecek diğer önemli noktalar aşağıdadır.

Sorgu Yürütme

Sorgular yoğun kaynak kullanabileceğinden, kodunuzun hangi noktasında ve hangi bilgisayarda sorgu yürütülür göz önünde bulundurun.

Ertelenmiş yerine anında yürütme

Bir veya LINQ sorgusu oluşturduğunuzda ObjectQuery<T> , sorgu hemen yürütülmeyebilir. Sorgu yürütme, (C#) veya For Each (Visual Basic) numaralandırması veya bir koleksiyonu doldurmak List<T> üzere atanması gibi foreach sonuçlara ihtiyaç duyulana kadar ertelenebilir. Sorgu yürütme, veya ObjectQuery<T> üzerinde yöntemini çağırdığınızda Execute veya gibi FirstAnytek bir sorgu döndüren bir LINQ yöntemini çağırdığınızda hemen başlar. Daha fazla bilgi için bkz . Nesne Sorguları ve Sorgu Yürütme (LINQ to Entities).

LINQ sorgularının istemci tarafında yürütülmesi

LinQ sorgusunun yürütülmesi veri kaynağını barındıran bilgisayarda gerçekleşse de, linq sorgusunun bazı bölümleri istemci bilgisayarda değerlendirilebilir. Daha fazla bilgi için Sorgu Yürütmesi'nin (LINQ to Entities) Store Execution bölümüne bakın.

Sorgu ve Eşleme Karmaşıklığı

Tek tek sorguların karmaşıklığı ve varlık modelindeki eşlemenin sorgu performansı üzerinde önemli bir etkisi olacaktır.

Eşleme karmaşıklığı

Kavramsal modeldeki varlıklarla depolama modelindeki tablolar arasında basit bire bir eşlemeden daha karmaşık olan modeller, bire bir eşlemesi olan modellerden daha karmaşık komutlar oluşturur.

Sorgu karmaşıklığı

Veri kaynağında yürütülen komutlarda çok sayıda birleştirme gerektiren veya büyük miktarda veri döndüren sorgular aşağıdaki yollarla performansı etkileyebilir:

  • Basit görünen kavramsal bir modele yönelik sorgular, veri kaynağında daha karmaşık sorguların yürütülmesine neden olabilir. Bunun nedeni Entity Framework'ün kavramsal modele karşı sorguyu veri kaynağına karşı eşdeğer bir sorguya çevirmesi olabilir. Kavramsal modeldeki tek bir varlık kümesi veri kaynağındaki birden fazla tabloyla eşlendiğinde veya varlıklar arasındaki bir ilişki birleştirme tablosuna eşlendiğinde, veri kaynağı sorgusunda yürütülen sorgu komutu bir veya daha fazla birleştirme gerektirebilir.

    Not

    ToTraceString Belirli bir sorgu için ObjectQuery<T> veri kaynağında yürütülen komutları görüntülemek için veya EntityCommand sınıflarının yöntemini kullanın. Daha fazla bilgi için bkz . Nasıl yapılır: Mağaza Komutlarını Görüntüleme.

  • İç içe Varlık SQL sorguları sunucuda birleşimler oluşturabilir ve çok sayıda satır döndürebilir.

    Aşağıda, projeksiyon yan tümcesinde iç içe sorgu örneği verilmiştir:

    SELECT c, (SELECT c, (SELECT c FROM AdventureWorksModel.Vendor AS c  ) As Inner2
    FROM AdventureWorksModel.JobCandidate AS c  ) As Inner1
    FROM AdventureWorksModel.EmployeeDepartmentHistory AS c

    Buna ek olarak, bu tür sorgular sorgu işlem hattının iç içe sorgular arasında nesnelerin çoğaltılmasıyla tek bir sorgu oluşturmasına neden olur. Bu nedenle, tek bir sütun birden çok kez çoğaltılabilir. SQL Server da dahil olmak üzere bazı veritabanlarında bu, TempDB tablosunun çok büyük büyümesine neden olabilir ve bu da sunucu performansını düşürebilir. İç içe sorguları yürütürken dikkatli olunmalıdır.

  • İstemci kaynakları sonuç kümesinin boyutuyla orantılı bir şekilde kullanan işlemler gerçekleştiriyorsa, büyük miktarda veri döndüren sorgular performansın düşmesine neden olabilir. Bu gibi durumlarda, sorgu tarafından döndürülen veri miktarını sınırlamayı göz önünde bulundurmalısınız. Daha fazla bilgi için bkz . Nasıl yapılır: Sorgu Sonuçlarında Sayfalandırma.

Entity Framework tarafından otomatik olarak oluşturulan tüm komutlar, veritabanı geliştiricisi tarafından açıkça yazılan benzer komutlardan daha karmaşık olabilir. Veri kaynağınızda yürütülen komutlar üzerinde açık denetime ihtiyacınız varsa, tablo değerli bir işleve veya saklı yordama eşleme tanımlamayı göz önünde bulundurun.

İlişki

En iyi sorgu performansı için varlıklar arasındaki ilişkileri hem varlık modelindeki ilişkilendirmeler hem de veri kaynağındaki mantıksal ilişkiler olarak tanımlamanız gerekir.

Sorgu Yolları

Varsayılan olarak, bir ObjectQuery<T>yürütürken ilişkili nesneler döndürülmüyor (ilişkileri temsil eden nesneler olsa da). İlgili nesneleri üç yoldan biriyle yükleyebilirsiniz:

  1. yürütülmeden önce ObjectQuery<T> sorgu yolunu ayarlayın.

  2. nesnesinin Load kullanıma açık olduğu gezinti özelliğinde yöntemini çağırın.

  3. LazyLoadingEnabled üzerindeki ObjectContext seçeneğini olarak trueayarlayın. Varlık Veri Modeli Tasarım Aracı ile nesne katmanı kodu oluşturduğunuzda bunun otomatik olarak yapıldığını unutmayın. Daha fazla bilgi için bkz. Oluşturulan Koda Genel Bakış.

Hangi seçeneği kullanacağınızı düşündüğünüzde, veritabanına yönelik istek sayısı ile tek bir sorguda döndürülen veri miktarı arasında bir denge olduğunu unutmayın. Daha fazla bilgi için bkz . İlgili Nesneleri Yükleme.

Sorgu yollarını kullanma

Sorgu yolları, bir sorgunun döndürdüğü nesnelerin grafiğini tanımlar. Bir sorgu yolu tanımladığınızda, yolun tanımladığı tüm nesneleri döndürmek için veritabanına karşı yalnızca tek bir istek gerekir. Sorgu yollarının kullanılması, basit görünen nesne sorgularından veri kaynağında karmaşık komutların yürütülmesine neden olabilir. Bunun nedeni, tek bir sorguda ilgili nesneleri döndürmek için bir veya daha fazla birleştirmenin gerekli olmasıdır. Devralma içeren bir varlık veya çoka çok ilişkileri içeren bir yol gibi karmaşık bir varlık modeline yönelik sorgularda bu karmaşıklık daha fazladır.

Not

ToTraceString bir tarafından ObjectQuery<T>oluşturulacak komutu görmek için yöntemini kullanın. Daha fazla bilgi için bkz . Nasıl yapılır: Mağaza Komutlarını Görüntüleme.

Sorgu yolu çok fazla ilgili nesne içeriyorsa veya nesneler çok fazla satır verisi içeriyorsa, veri kaynağı sorguyu tamamlayamayabilir. Sorgu, veri kaynağının özelliklerini aşan ara geçici depolama gerektiriyorsa bu durum oluşur. Bu durumda, ilgili nesneleri açıkça yükleyerek veri kaynağı sorgusunun karmaşıklığını azaltabilirsiniz.

veya EntityReference<TEntity>döndüren EntityCollection<TEntity> bir gezinti özelliğinde yöntemini çağırarak Load ilgili nesneleri açıkça yükleyebilirsiniz. Nesneleri açıkça yüklemek için her çağrılışında Load veritabanına gidiş dönüş gerekir.

Not

döndürülen nesneler koleksiyonunda döngü yaparken çağırırsanız Load , örneğin deyimini foreach kullandığınızda (For Each Visual Basic'te), veri kaynağına özgü sağlayıcının tek bir bağlantıda birden çok etkin sonuç kümesini desteklemesi gerekir. SQL Server veritabanı için sağlayıcı bağlantı dizesi değerini MultipleActiveResultSets = true belirtmeniz gerekir.

Varlıklarda veya EntityReference<TEntity> özellikleri olmadığında EntityCollection<TEntity> yöntemini de kullanabilirsinizLoadProperty. Bu, POCO varlıklarını kullanırken kullanışlıdır.

İlişkili nesnelerin açıkça yüklenmesi birleşim sayısını azaltacak ve yedekli veri miktarını azaltacak olsa da, Load veritabanına yinelenen bağlantılar gerektirir ve bu da çok sayıda nesne açıkça yüklenirken maliyetli olabilir.

Değişiklikleri Kaydetme

bir ObjectContextüzerinde yöntemini çağırdığınızdaSaveChanges, bağlamda eklenen, güncelleştirilen veya silinen her nesne için ayrı bir oluşturma, güncelleştirme veya silme komutu oluşturulur. Bu komutlar veri kaynağında tek bir işlemde yürütülür. Sorgularda olduğu gibi oluşturma, güncelleştirme ve silme işlemlerinin performansı, kavramsal modeldeki eşlemenin karmaşıklığına bağlıdır.

Dağıtılmış İşlemler

Dağıtılmış işlem düzenleyicisi (DTC) tarafından yönetilen kaynakları gerektiren açık bir işlemdeki işlemler, DTC gerektirmeyen benzer bir işlemden çok daha pahalı olacaktır. DTC'ye yükseltme aşağıdaki durumlarda gerçekleşir:

  • BIR SQL Server 2000 veritabanına veya her zaman açık işlemleri DTC'ye yükselten başka bir veri kaynağına karşı bir işlem içeren açık bir işlem.

  • Bağlantı Entity Framework tarafından yönetildiğinde SQL Server 2005'e karşı bir işlem içeren açık bir işlem. Bunun nedeni SQL Server 2005'in, entity Framework'ün varsayılan davranışı olan tek bir işlem içinde bir bağlantı kapatıldığında ve yeniden açıldığında DTC'ye yükseltmesidir. BU DTC yükseltmesi SQL Server 2008 kullanılırken gerçekleşmez. SQL Server 2005 kullanırken bu yükseltmeyi önlemek için işlem içindeki bağlantıyı açıkça açmanız ve kapatmanız gerekir. Daha fazla bilgi için bkz. Bağlan yonları ve İşlemleri Yönetme.

Bir işlem içinde bir veya daha fazla işlem yürütürken açık bir System.Transactions işlem kullanılır. Daha fazla bilgi için bkz. Bağlan yonları ve İşlemleri Yönetme.

Performansı Geliştirme Stratejileri

Aşağıdaki stratejileri kullanarak Entity Framework'teki sorguların genel performansını geliştirebilirsiniz.

Görünümleri önceden oluşturma

Bir varlık modelini temel alan görünümler oluşturmak, bir uygulamanın sorguyu ilk kez yürütmesinin önemli bir maliyetidir. Tasarım sırasında projeye eklenebilen bir Visual Basic veya C# kod dosyası olarak görünümleri önceden oluşturmak için EdmGen.exe yardımcı programını kullanın. Önceden derlenmiş görünümler oluşturmak için Metin Şablonu Dönüştürme Araç Seti'ni de kullanabilirsiniz. Önceden oluşturulmuş görünümler, belirtilen varlık modelinin geçerli sürümüyle tutarlı olduklarından emin olmak için çalışma zamanında doğrulanır. Daha fazla bilgi için bkz . Nasıl yapılır: Sorgu Performansını Geliştirmek için Görünümleri Önceden Oluşturma.

Çok büyük modellerle çalışırken aşağıdaki noktalar geçerlidir:

.NET meta veri biçimi, belirli bir ikili dosyadaki kullanıcı dizesi karakter sayısını 16.777.215 (0xFFFFFF) ile sınırlar. Çok büyük bir model için görünümler oluşturuyorsanız ve görünüm dosyası bu boyut sınırına ulaşırsa, "Daha fazla kullanıcı dizesi oluşturmak için mantıksal alan kalmadı" derleme hatası alırsınız. Bu boyut sınırlaması tüm yönetilen ikili dosyalar için geçerlidir. Daha fazla bilgi için büyük ve karmaşık modellerle çalışırken hatanın nasıl önlendiğini gösteren bloga bakın.

Sorgular için NoTracking birleştirme seçeneğini kullanmayı göz önünde bulundurun

Nesne bağlamında döndürülen nesneleri izlemek için gereken bir maliyet vardır. Nesnelerdeki değişiklikleri algılamak ve aynı mantıksal varlık için birden çok isteğin aynı nesne örneğini döndürmesini sağlamak, nesnelerin bir ObjectContext örneğe eklenmesini gerektirir. Nesnelerde güncelleştirme veya silme yapmayı planlamıyorsanız ve kimlik yönetimine ihtiyacınız yoksa, sorguları yürütürken birleştirme seçeneklerini kullanmayı NoTracking göz önünde bulundurun.

Doğru miktarda veri döndürme

Bazı senaryolarda, yöntemini kullanarak Include bir sorgu yolu belirtmek çok daha hızlıdır çünkü veritabanına daha az gidiş dönüş gerektirir. Ancak diğer senaryolarda, daha az birleştirmeye sahip daha basit sorgular verilerin daha az yedekliliğine neden olduğundan, ilgili nesneleri yüklemek için veritabanına ek gidiş dönüşler daha hızlı olabilir. Bu nedenle, ilgili nesneleri almak için çeşitli yolların performansını test etmenizi öneririz. Daha fazla bilgi için bkz . İlgili Nesneleri Yükleme.

Tek bir sorguda çok fazla veri döndürmemek için sorgu sonuçlarını daha yönetilebilir gruplara sayfalandırmayı göz önünde bulundurun. Daha fazla bilgi için bkz . Nasıl yapılır: Sorgu Sonuçlarında Sayfalandırma.

ObjectContext kapsamını sınırlama

Çoğu durumda, bir ObjectContext deyimi içinde (Using…End UsingVisual Basic'te) bir using örnek oluşturmanız gerekir. Bu, kod deyim bloğundan çıktığında nesne bağlamıyla ilişkili kaynakların otomatik olarak atılmasını sağlayarak performansı artırabilir. Ancak, denetimler nesne bağlamı tarafından yönetilen nesnelere bağlı olduğunda, ObjectContext bağlama gerekli olduğu ve el ile atıldığı sürece örnek korunmalıdır. Daha fazla bilgi için bkz. Bağlan yonları ve İşlemleri Yönetme.

Veritabanı bağlantısını el ile açmayı göz önünde bulundurun

Uygulamanız veri kaynağında oluşturma, güncelleştirme ve silme işlemlerini kalıcı hale getirmek için bir dizi nesne sorgusu veya sık sık çağrı SaveChanges yürüttüğünde, Entity Framework'ün veri kaynağı bağlantısını sürekli olarak açması ve kapatması gerekir. Bu gibi durumlarda, bu işlemlerin başlangıcında bağlantıyı el ile açmayı ve işlemler tamamlandığında bağlantıyı kapatmayı veya yok etmeyi göz önünde bulundurun. Daha fazla bilgi için bkz. Bağlan yonları ve İşlemleri Yönetme.

Performans Verileri

Entity Framework için bazı performans verileri, ADO.NET ekip blogunda aşağıdaki gönderilerde yayımlanır:

Ayrıca bkz.