Чому IIS за замовчуванням переробляє пул додатків кожні 1740 хвилин?

Чому IIS за замовчуванням переробляє пул додатків через певний час? Чи є якась конкретна причина, окрім, можливо, більшість веб-додатків не керує пам’яттю розсудливо? З огляду на те, що ви правильно керуєте пам'яттю програми, чи безпечно йти вперед та вимикати це? Які потенційні сторони можуть бути вигідними для того, щоб вимкнути утилізацію чи тримати її?

Так, причина, через яку він перебуває за замовчуванням один раз на день, не викликає занепокоєння у тому, що веб-додаток може витік пам'яті. Найбільшим недоліком часто переробляти пули програм IIS є те, що це спричинить читання web.config, завантаження збірки та перекомпіляцію сторінок asp.net та (якщо ви не вірите в попереднє їх складання) код позаду. Це досить важкий процес, і він не відбувається до наступного запиту на сторінку після рециркуляції пулу додатків, що значно уповільнює конкретний запит. Тепер у IIS7 є модуль, який ви можете завантажити " Warm Up Application", щоб допомогти "вирішити" цю проблему.

Я особисто вважаю за краще використовувати максимум на основі пам'яті в поєднанні з реєстрацією при запуску програми, а не планувати свою переробку. Це дозволяє мені припустити, що в моєму додатку немає витоку пам’яті та виявляється неправильним, коли пул додатків переробляється.

1740 хвилин - 29 годин:

Ще коли розроблявся IIS 6 - це версія, яка запроваджувала пули програм - за замовчуванням потрібно встановити регулярний інтервал часу, коли пули програм автоматично переробляються.

Уейд запропонував 29 годин з тієї простої причини, що це найменше просте число за 24 . Він хотів поступовий і неповторюваний візерунок, який зустрічається не частіше, ніж раз на день. Словами Уейда: "у вас не виникає резонансної картини". За замовчуванням минуло 1740 хвилин (29 годин)!

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

Особливість - це захоплення від класичних ASP днів, коли все просочилося пам’яттю і вам довелося це зробити. Більшість людей провели плановий перезапуск на веб-сервері протягом ночі. IIS6 автоматизував це за допомогою вимкнення пулу додатків кожні 1740 хвилин (або якщо програма працює в режимі очікування протягом 20 хвилин). IIS7 продовжив традицію.

Порада, яку я отримав від Microsoft в ті часи, полягала в тому, що це було непотрібно, якщо у вас не було застарілого додатка з відомим витоком пам'яті. Тож якби ви працювали з чисто керованим кодом, було б добре.

Вимкніть його та стежте за пулами програм. Більшість складних корпоративних програм використовують безліч застарілих кодів, і більша частина цього коду начебто є простою. Тому для більшості встановлень періодично перезапускати пул додатків - це не погана ідея.

Є й інші варіанти, такі як моніторинг часу бездіяльності, які можуть бути кращим рішенням для вашої ситуації.

Відкручування пулу додатків може зайняти деякий час і зробити програму менш чуйною, тому їх збереження може сприяти підвищенню продуктивності.

Дійсно, це суто для очищення витікаючих ресурсів, які (можливо) можуть бути присутніми. 1740 хвилин - це не єдина подія. Це також відбувається після конкретної максимальної кількості запитів або після перевищення певної кількості оперативної пам'яті. Він досить добре зафіксований у бібліотеці MSDN. На жаль, ця політика порушує такі факти, як стан сеансу та статику, наприклад, одиночні кнопки. Ваш додаток повинен бути достатньо надійним для повторної аутентифікації користувачів та / або повторної ініціалізації одиночних клавіш за необхідності, щоб уникнути порушення роботи користувача. Це змусило нас керувати автентифікованими сесіями в базі даних, а не в сесії ASP.NET. В іншому випадку наші користувачі завантажуються на нашу сторінку входу, коли сервер переробляється через один із цих тригерів.