Если я правильно помню (некоторое время назад я прочитал документы), наличие активных сеансов задержит обычный таймер перезапуска пула приложений (который срабатывает, когда ресурсы должны быть освобождены), поскольку сервер делает ставку на активные сеансы, что означает продолжение необходимость. По истечении времени сеансов (и запуска события session_end) таймер перезапуска приложения запускается снова и начинает обратный отсчет, в конце концов запускается, прежде чем пул потоков освобождает свои собственные ресурсы и завершает работу приложения.
То есть, при нормальных обстоятельствах, следует отметить, что событие session_end не гарантированно сработает (есть очень специфические сценарии, где это не так), я думаю, что сейчас это в основном связано с аварийными экземплярами IIS или приложения. Пул перерабатывает на OOM или ошибки. Раньше было так, что если вы не используете только один из типов сеансов (я считаю, что сервер состояний), он не будет надежно срабатывать. Теперь это может быть по-другому.
Если вам нужно гарантировать освобождение ресурсов, я не уверен, что session_end - подходящее место для этого. Можете ли вы повысить его до кэша приложений или HTTP-кэша и использовать уникальные ключи сеанса с периодическими событиями очистки? Это может быть более надежным (больше кода), но более надежным.
По моему общему опыту, session_end срабатывает довольно надежно, но я видел, как он выходит из строя при значительной нагрузке (100 хитов в секунду), и я знаю, что когда вы начинаете говорить о серверных фермах, это также значительно усложняется.