Почему этап обработки страницы AspNetSessionData задерживает мою страницу на 20+ секунд?

Question

У меня есть веб-приложение, которое использует ASP.NET с обработкой сеанса «InProc».Обычно все работает нормально, но несколько сотен запросов каждый день выполняются значительно дольше, чем обычно.В журналах IIS я вижу, что эти страницы (для запуска которых обычно требуется 2-5 секунд) работают в течение 20 с лишним секунд.

Я включил трассировку сбоев запросов в подробном режиме и обнаружил, что задержка составляетпроисходит в разделе AspNetSessionData.В примере, показанном ниже, между AspNetSessionDataBegin и AspNetSessionDataEnd был промежуток в 39 секунд.

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

Мое приложение обычно сохраняет 1-5 МБ в сеансе для каждого пользователя, в основном кэшированные данные для поиска.Сервер имеет много доступной памяти и работает только с 50 пользователями.

Answer 1

Это может быть вызвано конфликтом блокировок для состояния сеанса.Взгляните на последний абзац MSDN Обзор состояния сеанса ASP.NET .Смотрите также K.Полезный пост Скотта Аллена на эту тему.

Если страница помечена EnableSessionState = "True" (или наследуется по умолчанию для web.config), то все запросы на эту страницу получат блокировку записи насостояние сеанса.Все остальные запросы, которые используют состояние сеанса - даже если они не получают блокировку записи - блокируются до тех пор, пока этот запрос не завершится.

Если страница помечена EnableSessionState = "ReadOnly", то страница не будетполучить блокировку записи и поэтому не будет блокировать другие запросы.(Хотя он может быть заблокирован другим запросом, удерживающим блокировку записи.)

Чтобы устранить эту проблему блокировки, вы можете захотеть реализовать собственную [более детальную] блокировку вокруг HttpContext.Cache объект или статический WeakReference с.Последнее, вероятно, более эффективно.(См. Стр. 118-122 Сверхбыстрый ASP.NET Ричарда Киссига.)

Answer 2

Существует вероятность того, что вы используете максимальный объем памяти, который может использовать пул приложений, что приведет к перезапуску пула приложений (что будет учитывать задержку при доступе к сеансу).Объем памяти на сервере не влияет на объем памяти, который ASP.NET может использовать, это контролируется в файле machine.config в свойстве memoryLimit, а в IIS 6.0 позже в самом IIS - с помощью свойства «Максимальное использование памяти».Кроме того, рассматривали ли вы альтернативы для каждого пользователя, использующего 5 МБ памяти сеанса?Это не будет хорошо масштабироваться и может вызвать много проблем, когда вы находитесь под нагрузкой.Может ли кэширование стать более эффективным решением?Поиск занимает так много времени, что вам нужно это сделать, можно ли оптимизировать настройку SQL / Database для ускорения ваших запросов?