Запросы, зависающие на модуле сеанса в IIS 7.5

Время от времени некоторые запросы на моем сайте начинают зависать в состоянии RequestAcquireState модуля Session. Когда эта спираль начинает весь тайм-аут запросов и нам нужно перезапустить IIS на зараженном сервере.

Я исследовал его много, и единственный вывод, который я получил, заключается в том, что происходит какой-то тупик, когда приложение пытается получить доступ к пользовательским данным, хранящимся в сеансе.

Единственный вариант, который я могу решить, чтобы исправить эту проблему, - либо уменьшить, либо остановить использование сеансов в моем приложении. Это определенно часть плана, но это займет некоторое время, прежде чем мы сможем это сделать.

В нашем балансе нагрузки мы запускаем 6 машин с IIS 7.5, из состояния StateServer и сервера.

Любые подсказки о том, как обойти эту проблему или исправить ее вообще, без необходимости полностью удалить сеансы?

Ответ 1

Механизм блокировки существует как на модуле провайдера, так и на сеансе (модуль сеанса IIS). Вы можете разработать собственный модуль сеанса, но вам все равно нужен провайдер без блокировки, или вы можете создать настраиваемый поставщик без блокировки, но вам все еще нужен модуль сеанса IIS, и его реализовать на этом уровне не так просто.

Решение UnlockedStateProvider [aka Unlocked]

Следуйте за белым кроликом: P (проверьте демонстрационный проект, он объясняет все.)

Ответ 2

Ответ - это исправление Rollup 2828841 для .NET Framework 4.5, здесь все объяснение:

http://forums.asp.net/t/1888889.aspx/2/10?Question+regarding+a+possible+bug+within+NET+4+5

и здесь ссылка для скачивания

Он работает для меня на IIS 7.5 Windows Server 2008 rs x64, приложение веб-форм asp.net с большим количеством запросов ajax.

Ответ 3

Я только что узнал сегодня, что если у вас длинный запрос (или в моем случае - бесконечный цикл), тогда все последующие запросы будут заблокированы, потому что по умолчанию ASP.NET блокирует сеанс.

Итак, если у вас есть пользователи с запросами в RequestAcquireState, проверьте, есть ли запрос в ExecuteRequestHandler, который блокирует сеанс, и тем самым предотвращает запуск других запросов.

Существует обсуждение здесь о том, как предотвратить блокировку при сеансе. (В основном, создайте большую часть ваших страниц как Session-Read-Only и измените сеанс как можно реже.)

Ответ 4

Возможно ли, что у этих пользователей есть еще один длинный запрос, и запросы, которые вы видите, нагромождены, на самом деле являются вторичными запросами? По умолчанию ASP.NET блокирует сеанс до тех пор, пока запрос не будет завершен. Если второй запрос приходит до того, как первый будет завершен, ему придется подождать. Если вы используете MVC, вы можете изменить это поведение, добавив атрибут к вашему контроллеру.

[SessionState (SessionStateBehavior.ReadOnly)]

Это делает сеанс только для чтения, устраняя поведение блокировки, позволяющее обрабатывать последующие запросы.