Mengapa proses pekerja IIS mendaur ulang setiap 29 jam dan tidak setiap 24 jam?

Saat Anda menyiapkan situs di IIS, proses default pekerja untuk mendaur ulang setiap 1740 menit (29 jam). Mengapa angka ganjil seperti 29 jam dan tidak, misalnya, 24 atau 48 jam?

Di Tech Ed 2003, presenter ditanyai pertanyaan ini, dan jawabannya adalah mereka ingin siklus tidak teratur untuk mencegahnya terjadi pada batas harian (misalnya untuk membedakan dari tugas-tugas harian lainnya yang dijadwalkan pada server / domain).

Situs di sini (Tautan mati) berspekulasi:

... (29 adalah) prime pertama setelah 24, yang memungkinkannya untuk memiliki kesempatan paling kecil terjadi dalam pola reguler dengan proses server lainnya; memudahkan penyelidikan ke dalam masalah

Situs lain muncul untuk mengonfirmasi ini:

( Wade Hilmo ) 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 per hari.

OK, ini menggangguku, jadi aku menggali dan akhirnya menemukan postingan ini dari seorang pria yang ternyata ada di tim IIS:

Alasan IIS6 mendaur ulang setiap 29 jam secara default (dan kami punya alasan

Alasan IIS6 mendaur ulang setiap 29 jam secara default (dan kami memiliki alasan untuk memilih 29 jam sebagai nilai default) adalah karena lebih mungkin daripada tidak, aplikasi web yang menjalankannya tidak dapat diandalkan dan benar-benar perlu memulai kembali secara berkala.

Dengan demikian, IIS6 dibangun di sekitar premis (diakui sinis) bahwa aplikasi web pengguna tidak akan berjalan selama lebih dari 24 jam yang berdekatan, fitur-fitur direncanakan sesuai, dan standar dipilih. Proses pekerja mendaur ulang setiap 29 jam, proses startup dan shutdown dimonitor, proses ini terus-menerus dilakukan ping untuk memastikannya berjalan, proses handle dilacak dan diberi tanda ketika berhenti secara tiba-tiba, dll.

Menyadari bahwa daur ulang adalah bagian normal dari operasi, IIS6 juga memastikan untuk mengisolasi daur ulang tersebut dari pengguna akhir - koneksi TCP pengguna akhir tidak pernah berakhir selama daur ulang, karena beberapa keajaiban mode kernel. Dikombinasikan dengan aplikasi mode pengguna yang menyimpan sesi-negara out-of-proses (seperti ASP.Net Session State Service), satu hampir dijamin dapat diandalkan uptime tanpa kehilangan data yang terlihat pengguna, bahkan jika aplikasi web crash setelah memproses setiap satu permintaan pengguna.

Ini sama baiknya dengan IIS6 yang dapat membuatnya - mengingat aplikasi web yang tidak dapat diandalkan, membuatnya tampak dapat diandalkan oleh pengguna akhir, dan melakukannya tanpa memerlukan perbaikan apa pun dari aplikasi web yang tidak dapat diandalkan.

Tentu saja, tidak semua aplikasi yang tidak dapat diandalkan dapat dibuat tampak andal - jika demikian, maka kita semua kehilangan pekerjaan! - tetapi IIS6 benar-benar mencoba lebih banyak untuk menjadi tangguh.

Dalam kasus Anda, kebetulan bahwa resiliancy memiliki efek samping pada status pengguna yang tidak bertahan, tetapi dapat dengan mudah disesuaikan.

Dengan asumsi aplikasi web Anda tidak pernah memiliki masalah dan tetap dengan status sesi dalam proses, Anda akan ingin mengubah default ini: 1. Matikan daur ulang berkala 29 jam 2. Matikan batas waktu idle 20 menit

Ini akan mencegah hilangnya status sesi yang tidak terduga.

Tentu saja, jika Anda pernah menggunakan aplikasi dengan status sesi out-of-proses, Anda dapat meninggalkan semuanya sebagai default dan tidak pernah melihat perbedaan dalam fungsionalitas atau keandalan.