Рекомендации по ограничению сеансов ASP.NET
Мы запускаем приложение PaaS ASP.NET в службе приложений Azure с 3 экземплярами и управляем выходной обработкой данных сеанса в базе данных SQL Server.
Приложение работает, и мы заметили большое количество данных сеанса для некоторых пользователей при переходе по определенным путям, например. у некоторых пользователей данные сеанса превышают 500 тыс. (для простого посещения сайта без входа в систему средний сеанс составляет около отметки 750–3000, чего я и ожидал).
500 КБ звучит чрезмерно, но мне было интересно, что в наши дни нормально для крупных корпоративных приложений, а также минусы хранения такого большого количества данных в сеансе.
Мои первоначальные мысли были бы,
- Не влияет на ЦП веб-приложения (фактически возможно снижение), поскольку запросы не выполняются постоянно,
- Не влияет на память веб-приложения, потому что мы используем outproc,
- Большие всплески DTU в базе данных сеанса Sql Server при запуске сборки мусора,
- Приложение может работать немного медленнее, потому что для чтения и записи данных сеанса между запросами требуется больше времени.
- Может не подходить для пользователей с плохим подключением к Интернету,
- Возможное увеличение утечек памяти, если объекты не определены правильно.
Мои рассуждения имеют смысл или я что-то упустил?
Любые мысли и советы будут оценены,
Большое спасибо.
Ответы 1
Я полностью согласен с вашими доводами в пользу использования управления сеансами вне процесса в экземплярах приложений Azure. Использование сеансов IN-PROC в облаке — категорически нет. Причиной размещения в облаке является высокая доступность, которая достигается за счет наличия распределенной среды.
Понимая с вашей точки зрения, я предполагаю, что скорость беспокоит вас или имеет значение для большинства веб-приложений. Чтобы преодолеть это, вы можете подумать об использовании кеша Azure Redis.
Вот статья о настройке управления сеансом с помощью кэша Azure Redis:
См. документацию здесь: https://docs.microsoft.com/en-us/azure/redis-cache/cache-aspnet-session-state-provider
Спасибо Мохит за ваш отзыв. Да, мы использовали Redis, но отключили его, потому что он не обрабатывал наши большие данные сеанса. Насколько я понимаю, Redis работает быстро, но только если размер ваших данных не слишком велик. Он может обрабатывать множество ключей, но размер ключа (или пары) не может быть слишком большим. Я подозреваю, что мы достигли верхних пределов, поэтому у нас начались проблемы с этим.