Entity Framework "nasıl ısınır"? Hava ne zaman “soğur”?

Hayır, ikinci sorumun cevabı kış değil.

Önsöz:

Son zamanlarda Entity Framework üzerinde çok araştırma yapıyorum ve beni rahatsız eden bir şey, sorgular ısınmadığında, yani soğuk sorgular olarak adlandırılan performansı.

Ben geçti performans hususlar Varlık Framework 5.0 için makale. Yazarlar, Sıcak ve Soğuk sorgular kavramını ve bunların nasıl farklılaştığını ortaya koydu, ben de bunların varlığını bilmeden kendim fark ettim. Burada, arkamda sadece altı aylık bir deneyime sahip olduğumdan bahsetmeye değer.

Artık çerçeveyi performans açısından daha iyi anlamak istersem ek olarak hangi konuları araştırabileceğimi biliyorum. Maalesef İnternetteki bilgilerin çoğu güncelliğini yitirmiş veya öznellikle şişirilmiş durumda, bu nedenle Sıcak ve Soğuk sorgular konusunda herhangi bir ek bilgi bulamıyorum .

Temel olarak şu ana kadar fark ettiğim şey, ne zaman yeniden derlemem gerekirse veya geri dönüşüm isabetleri, ilk sorgularım çok yavaşlıyor. Daha sonra okunan herhangi bir veri , beklendiği gibi hızlıdır ( özneldir ).

Windows Server 2012, IIS8 ve SQL Server 2012'ye geçeceğiz ve bir Junior olarak aslında onları diğerlerinden önce test etme fırsatı kazandım. Başvurumu ilk talebe hazır hale getirecek bir ısınma modülünü sundukları için çok mutluyum. Ancak, Entity Framework'ümü ısıtmaya nasıl devam edeceğimi bilmiyorum.

Zaten bildiğim şey yapmaya değer:

• Görüşlerimi önerildiği gibi önceden oluşturun.
• Sonunda modellerimi ayrı bir montaja taşıyın.

Sağduyu ile devam ederek, muhtemelen yanlış bir yaklaşımla yapmayı düşündüğüm şey :

• Bir şeyleri ısıtmak, modelleri oluşturmak ve doğrulamak için Uygulama Başlangıcında sahte veri okur.

Sorular:

• Entity Framework'ümde herhangi bir zamanda yüksek kullanılabilirliğe sahip olmak için en iyi yaklaşım ne olurdu?
• Entity Framework hangi durumlarda yeniden "soğuk" olur? (Yeniden Derleme, Geri Dönüşüm, IIS Yeniden Başlatma vb.)

• Entity Framework'ümde herhangi bir zamanda yüksek kullanılabilirliğe sahip olmak için en iyi yaklaşım ne olurdu?

Önceden oluşturulmuş görünümler ve statik derlenmiş sorguların bir karışımına gidebilirsiniz.

Static CompiledQuerys iyidir çünkü yazmaları hızlı ve kolaydır ve performansı artırmaya yardımcı olurlar. Ancak EF5 ile tüm sorgularınızı derlemenize gerek yoktur çünkü EF, sorguları otomatik olarak derleyecektir. Tek sorun, önbellek tarandığında bu sorguların kaybolabilmesidir. Bu nedenle, yalnızca çok nadir görülen ancak pahalı olan kendi derlenmiş sorgularınıza referanslar tutmak istiyorsunuz. Bu sorguları statik sınıflara koyarsanız, ilk ihtiyaç duyulduğunda derleneceklerdir. Bu, bazı sorgular için çok geç olabilir, bu nedenle uygulama başlatılırken bu sorguların derlenmesini zorlamak isteyebilirsiniz.

Önceden ortaya çıkan görüşler de bahsettiğiniz diğer olasılık. Özellikle, derlenmesi çok uzun süren ve değişmeyen sorgular için. Bu şekilde, performans ek yükünü çalışma zamanından derleme süresine taşırsınız. Ayrıca bu herhangi bir gecikmeye neden olmaz. Ancak elbette bu değişiklik veri tabanına aktarılıyor, bu yüzden başa çıkmak o kadar kolay değil. Kod daha esnektir.

Çok fazla TPT kalıtımı kullanmayın (bu, EF'te genel bir performans sorunudur). Miras hiyerarşilerinizi ne çok derin ne de çok geniş inşa etmeyin. Yalnızca bazı sınıfa özgü 2-3 özellik, kendi türü gerektirmek için yeterli olmayabilir, ancak mevcut bir türe isteğe bağlı (null yapılabilir) özellikler olarak işlenebilir.

Uzun süre tek bir içeriğe bağlı kalmayın. Her bağlam örneğinin kendi birinci seviye önbelleği vardır ve bu, büyüdükçe performansı yavaşlatır. Bağlam oluşturma ucuzdur, ancak bağlamın önbelleğe alınmış varlıkları içindeki durum yönetimi pahalı hale gelebilir. Diğer önbellekler (sorgu planı ve meta veriler) bağlamlar arasında paylaşılır ve AppDomain ile birlikte ölür.

Sonuç olarak, bağlamları sık sık ayırdığınızdan ve bunları yalnızca kısa bir süre için kullandığınızdan, uygulamanızı hızlı bir şekilde başlatabildiğinizden, nadiren kullanılan sorguları derlediğinizden ve performans açısından kritik olan ve sıklıkla kullanılan sorgular için önceden oluşturulmuş görünümler sağladığınızdan emin olmalısınız.

• Entity Framework hangi durumlarda yeniden "soğuk" olur? (Yeniden Derleme, Geri Dönüşüm, IIS Yeniden Başlatma vb.)

Temel olarak, AppDomain'inizi her kaybettiğinizde. IIS her 29 saatte bir yeniden başlatır , bu nedenle örneklerinizin etrafta olacağının garantisini veremezsiniz. Ayrıca bir süre etkinlik olmadığında AppDomain de kapatılır. Hızlıca tekrar yukarı çıkmaya çalışmalısın. Belki bazı başlatma işlemlerini eşzamansız olarak yapabilirsiniz (ancak çoklu iş parçacığı sorunlarına dikkat edin). AppDomain'in ölmesini engellemek için herhangi bir istek olmadığı zamanlarda uygulamanızda sahte sayfalar çağıran planlanmış görevleri kullanabilirsiniz, ancak sonunda olacaktır.

Ayrıca, yapılandırma dosyanızı değiştirdiğinizde veya derlemeleri değiştirdiğinizde yeniden başlatma olacağını varsayıyorum.

Tüm aramalarda maksimum performans arıyorsanız, mimarinizi dikkatlice düşünmelisiniz. Örneğin, uygulama her istekte veritabanı çağrıları kullanmak yerine yüklendiğinde sunucu RAM'inde sık kullanılan aramaları önceden önbelleğe almak mantıklı olabilir. Bu teknik, yaygın olarak kullanılan veriler için minimum uygulama yanıt sürelerini sağlayacaktır. Bununla birlikte, eşzamanlılıkla ilgili sorunları önlemek için önbelleğe alınan verileri etkileyen her değişiklik yapıldığında, iyi bir son kullanma politikasına sahip olduğunuzdan veya her zaman önbelleğinizi temizlediğinizden emin olmalısınız.

Genel olarak, dağıtılmış mimarileri yalnızca yerel olarak önbelleğe alınan bilgiler eskimiş olduğunda veya işlemsel olması gerektiğinde GÇ tabanlı veri taleplerini gerektirecek şekilde tasarlamaya çalışmalısınız. Herhangi bir "kablo üzerinden" veri talebinin alınması, normalde bellek önbelleği alımında yerel bir önbellek alımından 10-1000 kat daha uzun sürer. Tek başına bu tek gerçek, "yerel ve uzak" veri sorununa kıyasla "soğuk veriye karşı sıcak veriler" hakkındaki tartışmaları önemsiz hale getirir.

Genel ipuçları.

• Neye erişildiği ve talep zamanı dahil olmak üzere titiz günlük kaydı gerçekleştirin .
• Önceki adımdan aldığınız çok yavaş istekleri ısıtmak için uygulamanızı başlatırken kukla istekler gerçekleştirin .
• Gerçek bir sorun olmadıkça optimize etme zahmetine girmeyin, uygulamanın tüketicisiyle iletişim kurun ve sorun. Yalnızca neyin optimizasyona ihtiyaç duyduğunu anlamak için sürekli bir geri bildirim döngüsüne sahip olun .

Şimdi, sahte isteklerin neden yanlış bir yaklaşım olmadığını açıklayalım .

• Daha Az Karmaşıklık - Uygulamayı, çerçevedeki değişikliklerden bağımsız olarak çalışacak şekilde ısıtıyorsunuz ve bunu doğru şekilde yapmak için muhtemelen ilginç API'leri / çerçeve iç bileşenlerini bulmanız gerekmiyor .
• Daha Fazla Kapsam - Yavaş istekle ilgili olarak tüm önbellek katmanlarını aynı anda ısıtıyorsunuz.

Bir önbelleğin ne zaman "Soğuk" olduğunu açıklamak için.

Bu , çerçevenizde bir önbellek uygulayan herhangi bir katmanda olur , performans sayfasının üst kısmında iyi bir açıklama vardır .

• Önbelleği eski yapan potansiyel bir değişiklikten sonra bir önbelleğin doğrulanması gerektiğinde, bu bir zaman aşımı veya daha akıllı olabilir (yani, önbelleğe alınan öğedeki değişiklik).
• Bir önbellek öğesi çıkarıldığında, bunu yapmak için gereken algoritma, bağladığınız performans makalesinin "Önbellek çıkarma algoritması" bölümünde açıklanmaktadır , ancak kısaca.
  • LFRU (En az sıklıkla - son zamanlarda kullanılan) 800 öğe sınırıyla isabet sayısı ve yaşta önbellek.

Bahsettiğiniz diğer şeyler, özellikle IIS'nin yeniden derlenmesi ve yeniden başlatılması, bellek önbelleklerinin bir kısmını veya tamamını temizler.

Belirttiğiniz gibi, gerçekten yapmanız gereken tek şey "önceden oluşturulmuş görünümler" kullanın.

Senin alıntı linke : "görünümleri oluşturulduğunda, onlar da doğrulanır bir performans açısından bakıldığında, görünüm nesil maliyetinin büyük çoğunluğunun görüş onaylanmasıdır."

Bu, model montajınızı oluşturduğunuzda performans vuruşunun gerçekleşeceği anlamına gelir. Bağlam nesneniz daha sonra "soğuk sorguyu" atlayacak ve bağlam nesnesi yaşam döngüsü ve sonraki yeni nesne bağlamları boyunca yanıt vermeye devam edecektir.

Alakasız sorguları yürütmek, sistem kaynaklarını tüketmekten başka bir amaca hizmet etmez.

Kısayol ...

1. Önceden oluşturulmuş görünümlerin tüm bu ekstra çalışmalarını atlayın
2. Nesne bağlamınızı oluşturun
3. O tatlı alakasız sorguyu ateşleyin
4. Ardından, işleminizin süresi boyunca nesne bağlamınıza bir referans verin (önerilmez).

Bu çerçevede deneyimim yok. Ancak diğer bağlamlarda, örneğin Solr'de, tüm DB'yi (veya dizini) önbelleğe alamadığınız sürece, tamamen sahte okumalar pek bir işe yaramayacaktır.

Daha iyi bir yaklaşım, sorguları günlüğe kaydetmek, günlüklerden en yaygın olanları çıkarmak ve onları ısınmak için kullanmak olacaktır. Devam etmeden önce ısınma sorgularını kaydetmediğinizden veya günlüklerden kaldırmadığınızdan emin olun.