Mengapa IIS default untuk Daur Ulang Pool Aplikasi setiap 1740 menit?

Mengapa IIS default untuk mendaur ulang kumpulan aplikasi setelah waktu tertentu? Apakah ada alasan khusus selain mungkin sebagian besar aplikasi web tidak mengelola memori dengan bijaksana? Mengingat Anda mengelola memori aplikasi dengan benar, apakah aman untuk melanjutkan dan mematikannya? Apa sajakah potensi sisi buruk, manfaat untuk mematikan daur ulang atau mempertahankannya?

Ya, alasan default untuk sekali sehari adalah karena khawatir aplikasi web bisa mengalami kebocoran memori. Kelemahan terbesar dari sering mendaur ulang kumpulan aplikasi IIS adalah bahwa hal itu akan menyebabkan pembacaan web.config, pemuatan perakitan, dan kompilasi ulang halaman asp.net dan (jika Anda tidak percaya pada pra-kompilasi) kode di belakang. Ini adalah proses yang agak berat dan tidak terjadi sampai permintaan berikutnya untuk halaman setelah kumpulan aplikasi telah didaur ulang, sangat memperlambat permintaan tertentu. IIS7 sekarang memiliki modul yang dapat Anda unduh yang disebut Application Warm Up untuk membantu "menangani" masalah ini.

Saya pribadi lebih suka menggunakan maksimum berbasis memori ditambah dengan masuk pada awal aplikasi daripada menjadwalkan daur ulang saya. Ini memungkinkan saya untuk menganggap aplikasi saya tidak memiliki kebocoran memori dan terbukti salah ketika kumpulan aplikasi didaur ulang.

1740 menit adalah 29 jam:

Kembali ketika IIS 6 sedang dikembangkan — yang merupakan versi yang memperkenalkan kumpulan aplikasi — standar yang perlu ditetapkan untuk Interval Waktu Reguler ketika kumpulan aplikasi secara otomatis didaur ulang.

Wade menyarankan 29 jam untuk alasan sederhana bahwa itu adalah bilangan prima terkecil di atas 24 . Dia menginginkan pola yang berulang dan tidak berulang yang tidak terjadi lebih sering dari sekali sehari. Dalam kata-kata Wade: "Anda tidak mendapatkan pola beresonansi". Standarnya adalah 1740 menit (29 jam) sejak!

http://weblogs.asp.net/owscott/archive/2013/04/06/why-is-the-iis-default-app-pool-recycle-set-to-1740-minutes.aspx

Fitur adalah peninggalan dari hari-hari ASP klasik ketika semuanya bocor memori dan Anda harus melakukannya. Kebanyakan orang memiliki jadwal restart di server web dalam semalam. IIS6 mengotomatiskan ini dengan shutdown app pool setiap 1740 menit (atau jika aplikasi idle selama 20 menit). IIS7 melanjutkan tradisi.

Saran yang saya dapatkan dari microsoft pada masa itu adalah bahwa ini tidak perlu kecuali Anda memiliki aplikasi lawas dengan kebocoran memori yang diketahui. Jadi, jika Anda menjalankan kode yang dikelola murni Anda akan baik-baik saja.

Matikan dan pantau kumpulan aplikasi. Sebagian besar aplikasi perusahaan yang kompleks menggunakan banyak kode lama dan banyak dari kode itu agak bocor. Jadi untuk sebagian besar pemasangan, aplikasi pool dihidupkan kembali sesekali bukan ide yang buruk.

Ada opsi lain seperti memantau waktu tidak aktif yang mungkin menjadi solusi yang lebih baik untuk situasi Anda.

Memutar kumpulan aplikasi dapat memakan waktu dan membuat aplikasi kurang responsif sehingga mempertahankannya dapat membantu kinerja.

Memang, ini murni untuk membersihkan sumber daya bocor yang (mungkin) hadir. 1740 menit juga bukan satu-satunya peristiwa yang memicu. Ini juga terjadi setelah jumlah maksimum permintaan tertentu atau setelah melebihi jumlah tertentu dari memori proses pekerja. Ini didokumentasikan dengan cukup baik di perpustakaan MSDN. Sayangnya, kebijakan ini merusak hal-hal seperti status sesi dan statika seperti lajang. Aplikasi Anda harus cukup kuat untuk mengautentikasi ulang pengguna dan / atau menginisialisasi ulang lajang yang diperlukan untuk menghindari gangguan pengalaman pengguna Anda. Itu memaksa kami untuk mengelola sesi terotentikasi dalam database daripada di sesi ASP.NET. Jika tidak, pengguna kami di-boot kembali ke halaman login kami setiap kali server didaur ulang karena salah satu pemicu ini.