Bagaimana cara "pemanasan" Kerangka Entitas? Kapan menjadi "dingin"?

118

Tidak, jawaban untuk pertanyaan kedua saya bukanlah musim dingin.

Kata pengantar:

Saya telah melakukan banyak penelitian tentang Entity Framework baru-baru ini dan sesuatu yang terus mengganggu saya adalah kinerjanya saat kueri tidak dipanaskan, yang disebut cold queries.

Saya membaca artikel pertimbangan kinerja untuk Entity Framework 5.0. Penulis memperkenalkan konsep pertanyaan Hangat dan Dingin dan bagaimana perbedaannya, yang juga saya perhatikan sendiri tanpa mengetahui keberadaannya. Di sini mungkin layak untuk disebutkan bahwa saya hanya memiliki pengalaman enam bulan di belakang saya.

Sekarang saya tahu topik apa yang dapat saya teliti tambahan jika saya ingin memahami kerangka kerja lebih baik dalam hal kinerja. Sayangnya sebagian besar informasi di Internet sudah usang atau membengkak dengan subjektivitas, oleh karena itu saya tidak dapat menemukan informasi tambahan tentang topik kueri Warm vs Cold .

Pada dasarnya apa yang saya perhatikan sejauh ini adalah bahwa setiap kali saya harus mengkompilasi ulang atau mendaur ulang, kueri awal saya menjadi sangat lambat. Setiap pembacaan data berikutnya cepat ( subyektif ), seperti yang diharapkan.

Kami akan bermigrasi ke Windows Server 2012, IIS8 dan SQL Server 2012 dan sebagai Junior saya benar-benar memenangkan kesempatan untuk mengujinya sebelum yang lain. Saya sangat senang mereka memperkenalkan modul pemanasan yang akan membuat aplikasi saya siap untuk permintaan pertama itu. Namun, saya tidak yakin bagaimana melanjutkan dengan pemanasan Kerangka Kerja Entitas saya.

Apa yang sudah saya ketahui layak dilakukan:

Hasilkan Tampilan saya sebelumnya seperti yang disarankan.
Akhirnya pindahkan model saya ke rakitan terpisah.

Apa yang saya pertimbangkan untuk dilakukan, dengan mengikuti akal sehat, mungkin pendekatan yang salah :

Melakukan pembacaan data dummy di Application Start untuk menghangatkan, menghasilkan, dan memvalidasi model.

Pertanyaan:

Apa pendekatan terbaik untuk mendapatkan ketersediaan tinggi di Kerangka Kerja Entitas saya kapan saja?
Dalam kasus apa Entity Framework menjadi "dingin" lagi? (Kompilasi Ulang, Daur Ulang, IIS Restart dll.)

— Peter
sumber

Cari tahu apakah ini pembuatan tampilan atau kompilasi kueri yang paling menarik bagi Anda. Jika ini adalah tampilan gen maka gunakan tampilan yang telah dikompilasi sebelumnya. Jika ini pertanyaannya - apakah Anda memiliki hierarki besar yang rumit? Perhatikan bahwa hal-hal mahal biasanya terjadi sekali per domain aplikasi dan di-cache oleh karena itu Anda melihat masalah seperti ini ketika domain aplikasi dibongkar dan yang baru dibuat.

— Pawel

Saya sudah menyebutkan pembuatan tampilan @Pawel, hierarkinya tidak rumit, bahkan tidak sedikit. Tapi masalahnya juga pokok. Mengikuti apa yang Anda katakan, saya akan mencari tahu kapan domain aplikasi sedang diturunkan. Namun, itu masih tidak membantu masalah lain yang menghangatkan Kerangka Entitas jika, seperti yang Anda katakan, domain aplikasi diturunkan. Pada titik ini, tampaknya domain aplikasi sedang diturunkan lebih dari yang seharusnya dan saya tidak yakin mengapa, daur ulang hanya di malam hari, pemalasan disetel ke 0.

— Peter

4

Menurut Anda mengapa melakukan pembacaan dummy data adalah pendekatan yang salah?

— Josh Heitzman

5

Rasanya tidak benar, saya pikir mungkin ada sesuatu yang lebih elegan yang tidak saya sadari. Tetapi jika itu satu-satunya solusi dan seseorang dengan pengetahuan yang baik dapat memastikan bahwa tidak ada cara lain, saya akan melakukannya.

— Peter

1

Satu masalah yang saya temui dengan app pool yang dimatikan setelah periode waktu non-aktivitas (karena lalu lintas rendah) adalah membuat layanan yang membuat permintaan pada interval waktu yang ditentukan ke salah satu halaman Anda. Ini mencegah penundaan yang lama sebelum kumpulan aplikasi dimulai ulang pada permintaan pertama. Atau Anda dapat menggunakan layanan gratis seperti www.pingalive.com untuk melakukan ping ke domain / ip Anda. Ini juga membantu mencegah objek cache Anda dihapus sebelum kedaluwarsa.

— hatsrumandcode

55

Apa pendekatan terbaik untuk mendapatkan ketersediaan tinggi di Kerangka Kerja Entitas saya kapan saja?

Anda dapat memilih campuran tampilan yang dibuat sebelumnya dan kueri kompilasi statis.

Static CompiledQuerys bagus karena cepat dan mudah ditulis serta membantu meningkatkan kinerja. Namun dengan EF5 tidak perlu mengkompilasi semua kueri Anda karena EF akan mengompilasi kueri itu sendiri secara otomatis. Satu-satunya masalah adalah kueri ini bisa hilang saat cache disapu. Jadi, Anda masih ingin menyimpan referensi ke kueri yang Anda kompilasi sendiri untuk kueri yang terjadi sangat jarang, tetapi itu mahal. Jika Anda menempatkan kueri tersebut ke dalam kelas statis, kueri tersebut akan dikompilasi saat pertama kali diperlukan. Ini mungkin sudah terlambat untuk beberapa kueri, jadi Anda mungkin ingin memaksa kompilasi kueri ini selama startup aplikasi.

Melihat sebelumnya adalah kemungkinan lain seperti yang Anda sebutkan. Terutama, untuk kueri yang membutuhkan waktu sangat lama untuk dikompilasi dan tidak berubah. Dengan cara itu Anda memindahkan overhead kinerja dari waktu proses ke waktu kompilasi. Juga ini tidak akan menyebabkan keterlambatan. Tapi tentu saja perubahan ini masuk ke database, jadi tidak mudah untuk mengatasinya. Kode lebih fleksibel.

Jangan gunakan banyak warisan TPT (itu masalah kinerja umum di EF). Jangan membangun hierarki warisan Anda terlalu dalam atau terlalu lebar. Hanya 2-3 properti khusus untuk beberapa kelas mungkin tidak cukup untuk meminta tipe sendiri, tetapi dapat ditangani sebagai properti opsional (nullable) untuk tipe yang ada.

Jangan berpegang pada satu konteks untuk waktu yang lama. Setiap contoh konteks memiliki cache tingkat pertama sendiri yang memperlambat kinerja saat tumbuh lebih besar. Pembuatan konteks itu murah, tetapi pengelolaan negara di dalam entitas yang di-cache dari konteks itu mungkin menjadi mahal. Cache lainnya (rencana kueri dan metadata) dibagikan antar konteks dan akan mati bersama dengan AppDomain.

Secara keseluruhan, Anda harus memastikan untuk sering mengalokasikan konteks dan menggunakannya hanya untuk waktu yang singkat, bahwa Anda dapat memulai aplikasi dengan cepat, bahwa Anda mengompilasi kueri yang jarang digunakan dan memberikan tampilan yang dibuat sebelumnya untuk kueri yang sangat penting bagi kinerja dan sering digunakan.

Dalam kasus apa Entity Framework menjadi "dingin" lagi? (Kompilasi Ulang, Daur Ulang, IIS Restart dll.)

Pada dasarnya, setiap kali Anda kehilangan AppDomain Anda. IIS melakukan restart setiap 29 jam , jadi Anda tidak pernah dapat menjamin bahwa Anda akan memiliki instans Anda. Juga setelah beberapa waktu tanpa aktivitas, AppDomain juga akan dimatikan. Anda harus mencoba untuk segera kembali. Mungkin Anda dapat melakukan beberapa inisialisasi secara asynchronous (tapi waspadalah terhadap masalah multi-threading). Anda dapat menggunakan tugas terjadwal yang memanggil halaman dummy dalam aplikasi Anda pada saat tidak ada permintaan untuk mencegah AppDomain mati, tetapi pada akhirnya akan mati.

Saya juga berasumsi ketika Anda mengubah file konfigurasi atau mengubah majelis, akan ada restart.

— Andreas
sumber

Terima kasih Andre, itulah yang saya butuhkan.

— Peter

@Andreas Sebenarnya, bahkan dengan kueri yang dikompilasi statis, proses pertama terlalu lama. Adakah cara untuk memanaskan hal-hal selain: Melakukan pembacaan data dummy pada Permulaan Aplikasi untuk menghangatkan, menghasilkan, dan memvalidasi model.

— manishKungwani

@Andreas Jadi Entity framework5 butuh atau tidak? apa bedanya jika menggunakannya di ef5 (maksud saya masih lambat atau sedikit adonan atau tidak berbeda?)

— qakmak

"Static CompiledQuerys bagus karena cepat dan mudah ditulis serta membantu mengurangi kinerja." Performa berkurang?

— Mathemats

9

Jika Anda mencari kinerja maksimum di semua panggilan, Anda harus mempertimbangkan arsitektur Anda dengan hati-hati. Misalnya, mungkin masuk akal untuk melakukan pra-cache yang sering digunakan pencarian di RAM server saat aplikasi dimuat daripada menggunakan panggilan database pada setiap permintaan. Teknik ini akan memastikan waktu respons aplikasi minimum untuk data yang umum digunakan. Namun, Anda harus yakin memiliki kebijakan kedaluwarsa yang berperilaku baik atau selalu menghapus cache Anda setiap kali ada perubahan yang memengaruhi data cache untuk menghindari masalah dengan konkurensi.

Secara umum, Anda harus berusaha merancang arsitektur terdistribusi agar hanya memerlukan permintaan data berbasis IO ketika informasi yang disimpan dalam cache secara lokal menjadi basi, atau perlu transaksional. Setiap permintaan data "over the wire" biasanya membutuhkan waktu 10-1000 kali lebih lama untuk diambil daripada permintaan data lokal dalam pengambilan cache memori. Fakta yang satu ini saja sering membuat diskusi tentang "data dingin vs. hangat" tidak penting dibandingkan dengan masalah data "lokal vs. jarak jauh".

— mcstar
sumber

Ini adalah poin bagus yang sering saya abaikan, sambil mulai bersemangat tentang kinerja mentah kerangka entitas. Saya akan mempelajari ini lebih lanjut dan meneliti lebih lanjut tentang prinsip-prinsip cache. Namun, "dingin vs. hangat" dalam istilah EF masih merupakan sesuatu yang ingin saya pahami lebih baik.

— Peter

2

"Fakta satu ini saja sering membuat diskusi tentang" data dingin vs. hangat "tidak penting dibandingkan dengan masalah data" lokal vs. jarak jauh ". Tidak juga. Jika Anda tidak memilikinya di-cache secara lokal (yang awalnya tidak Anda lakukan), Anda masih harus menekan EF dan mengalami kesulitan inisialisasi untuk membuat cache Anda menjadi prima. Tempat yang sama di mana cache Anda tidak diinisialisasi, EF akan tidak diinisialisasi. Jadi, menambahkan lapisan caching mungkin tidak membantu jika satu-satunya masalah adalah waktu inisialisasi EF, tetapi ini akan menambah lapisan kerumitan lainnya ...

— MikeJansen

8

Kiat umum.

Lakukan logging yang cermat termasuk apa yang diakses dan waktu permintaan .
Lakukan permintaan palsu saat menginisialisasi aplikasi Anda untuk memanaskan permintaan yang sangat lambat yang Anda ambil dari langkah sebelumnya.
Jangan repot-repot mengoptimalkan kecuali itu masalah nyata, komunikasikan dengan konsumen aplikasi dan tanyakan. Dapatkan kenyamanan memiliki umpan balik berkelanjutan jika hanya untuk mencari tahu apa yang membutuhkan pengoptimalan .

Sekarang untuk menjelaskan mengapa permintaan dummy bukanlah pendekatan yang salah .

Kurang Kompleksitas - Anda melakukan pemanasan aplikasi dengan cara yang akan berfungsi terlepas dari perubahan kerangka kerja, dan Anda tidak perlu mencari tahu API / internal kerangka kerja yang mungkin funky untuk melakukannya dengan cara yang benar .
Cakupan Lebih Besar - Anda sedang memanaskan semua lapisan caching sekaligus terkait dengan permintaan lambat.

Untuk menjelaskan kapan cache menjadi "Dingin".

Ini terjadi di setiap lapisan dalam kerangka Anda yang menerapkan cache, ada deskripsi yang bagus di bagian atas halaman kinerja .

Kapan pun cache harus divalidasi setelah potensi perubahan yang membuat cache basi, ini bisa menjadi waktu tunggu atau lebih cerdas (yaitu perubahan dalam item yang di-cache).
Saat item cache dikeluarkan, algoritme untuk melakukan ini dijelaskan di bagian "Algoritme penggusuran cache" di artikel performa yang Anda tautkan , namun singkatnya.
- LFRU (Paling jarang - baru-baru ini digunakan) cache berdasarkan jumlah hit dan usia dengan batas 800 item.

Hal lain yang Anda sebutkan, khususnya rekompilasi dan restart IIS menghapus sebagian atau semua cache memori.

— udoprog
sumber

Ini adalah jawaban lain yang membantu, sangat kami hargai.

— Peter

3

Seperti yang telah Anda nyatakan, gunakan "tampilan yang dibuat sebelumnya" yang benar-benar perlu Anda lakukan.

Diekstrak dari tautan Anda : "Saat tampilan dibuat, mereka juga divalidasi. Dari sudut pandang kinerja, sebagian besar biaya pembuatan tampilan sebenarnya adalah validasi tampilan"

Ini berarti ketukan kinerja akan terjadi saat Anda membangun perakitan model Anda. Objek konteks Anda kemudian akan melewati "kueri dingin" dan tetap responsif selama durasi siklus hidup objek konteks serta konteks objek baru berikutnya.

Menjalankan kueri yang tidak relevan tidak akan melayani tujuan lain selain untuk mengonsumsi sumber daya sistem.

Jalan pintas ...

Lewati semua pekerjaan ekstra dari tampilan yang dibuat sebelumnya
Buat konteks objek Anda
Luncurkan pertanyaan manis yang tidak relevan itu
Kemudian pertahankan referensi ke konteks objek Anda selama proses Anda (tidak disarankan).

— hotpie
sumber

3

Periksa ini: Menggunakan Template T4 untuk View Generation .

— kzfabi

2

Saya tidak punya pengalaman dalam kerangka ini. Tetapi dalam konteks lain, misalnya Solr, pembacaan yang benar-benar palsu tidak akan banyak berguna kecuali Anda dapat menyimpan cache seluruh DB (atau indeks).

Pendekatan yang lebih baik adalah dengan mencatat kueri, mengekstrak yang paling umum dari log dan menggunakannya untuk pemanasan. Pastikan untuk tidak mencatat kueri pemanasan atau menghapusnya dari log sebelum melanjutkan.

— estani
sumber