Плюсы и минусы использования ASP.NET Session State Server (вместо InProc)?

Question

Прежде чем я начну использовать сервер состояния сеанса, чтобы сделать состояние приложений более устойчивым в своих приложениях по сравнению с состоянием InProc, я хотел бы найти список плюсов и минусов для оценки.

Обновление 1 : Также о выживших повторных пулах приложений?

Обновление 2 : А как насчет продолжительности сеансов и их окончания?

Answer 1

Вот канонический анализ плюсов и минусов ваших трех вариантов из Сессионного состояния ASP.NET Роба Говарда статья:

• В процессе . Процесс будет работать лучше, потому что память состояния сеанса хранится в процессе ASP.NET. Для веб-приложений, размещенных на одном сервере, приложения, в которых пользователь гарантированно перенаправляется на правильный сервер, или когда данные о состоянии сеанса не являются критическими (в том смысле, что они могут быть перестроены или повторно заполнены) , это режим на выбор.

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

• SQL Server . Этот режим лучше всего использовать, когда надежность данных имеет основополагающее значение для стабильности приложения, поскольку база данных может быть кластеризована для сценариев сбоев. Производительность не такая высокая, как вне процесса, но компромисс - более высокий уровень надежности.

Параметры out-of-process (иначе «StateServer») и SQL-Server выдерживают перезапуски веб-приложений (включая циклический пул приложений), и оба делают данные сеанса доступными для нескольких серверов в кластере / ферме.

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

Тим Снит Состояние сеанса ASP.NET: вопросы архитектуры и производительности добавляет некоторую дополнительную информацию, а раздел MSDN о режимах состояния сеанса является надежным, современным источником .

Answer 2

State Server - отличный выбор для (!) . Зачем? Потому что это означает, что ваше приложение теперь совместимо с любыми внешними режимами хранения.

Если вы в настоящее время разрабатываете свой сайт с InProc и хотите перейти на StateServer или SqlServer позднее, у вас могут возникнуть проблемы с сериализацией. Не всегда, но так бывает.

Некоторые примеры включают (некоторые уже упоминались):

• Операторы начинают планировать регулярные повторы пулов приложений IIS без вашего ведома
• Память постоянно заканчивается
• Вы будете работать с балансировщиком нагрузки на производстве и не можете гарантировать, что тот же веб-сайт получит тот же запрос.

Поэтому, лучше разобраться с этим раньше, чем позже. Это только изменение конфигурации и запуск службы; Boom!

Что также означает, что, если вы решите пойти по совершенно другому маршруту хранения сеанса, например, используя Redis (распределенный ключ / хранилище значений) или RavenDB (база данных документов), вы уже отсортированы.

Это действительно хорошая инвестиция в 1 минуту работы. Теперь вы готовы к веб-фермам, балансировщикам нагрузки и любым другим системам управления сеансами, для которых вы решили создать прототип.

Answer 3

Я бы сказал, что одним из больших недостатков использования In_Proc является то, что состояние сеанса может быть потеряно в случае перезапуска пула приложений или домена. Это может произойти в любое время, например, если на сервере недостаточно памяти и т. Д. Я лично никогда не полагаюсь на сеанс In_Proc для всего, что вы не хотите терять. Я потратил часы на отладку сайтов со спорадическими проблемами только для того, чтобы найти его, потому что состояние сеанса было потеряно из-за того, что сервер имел мало ресурсов для повторного использования ресурсов (и, конечно, чем больше вы храните в сеансе, тем меньше серверных ресурсов вы запомните, если что-то пойдет не так, то, возможно, в какой-то момент пойдет не так!

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

В блоге IIS MSDN есть хорошая статья об этом .

Answer 4

Преимущества:
1. Вы можете получить доступ к одному и тому же состоянию сеанса на разных машинах.
2. То же состояние сеанса доступно после перезагрузки app_pool.

Недостатки:
1. Медленнее, чем в режиме обработки.
2. Все объекты в состоянии сеанса должны быть сериализуемыми.

Answer 5

Недостатки сессий в ASP.NET

• Каждая переменная хранится как объект. Это означает, что вам нужно преобразовать Object в определенный тип при чтении переменной сеанса.
  

• В дополнение к этому, если сессия пуста, объект будет нулевым. Прежде чем читать переменную сеанса, вы должны проверить ее на ноль. Даже если переменная инициализирована ранее, она может быть нулевой, потому что сеанс истек. Попытка использовать нулевое значение сеанса может вернуть исключение. Если значение переменной сеанса равно нулю, обычной практикой является использование некоторого значения по умолчанию вместо бессмысленного нуля. Если значение не является нулевым, вы должны преобразовать его в соответствующий тип, потому что все переменные сеанса являются типом объекта. Когда делаете все это, вы должны обратить внимание, чтобы избежать жесткого кодирования. Подробнее о чтении и записи переменных сеанса в масштабируемом и обслуживаемом виде вы можете прочитать в руководстве Как писать, читать и удалять переменные состояния сеанса.
  

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

• Данные сеанса не должны использоваться для хранения конфиденциальных данных. Существует вероятность того, что злоумышленник получит идентификатор сеанса обычного посетителя. Если состояние сеанса используется для хранения такой информации, как: «разрешить доступ к области администрирования или нет» или что-то подобное, злоумышленник может просмотреть конфиденциальные данные веб-сайта, личные данные других пользователей, изменить базу данных, удалить содержимое и т. Д.
  

• Если используется режим InProc, сеансы легко истощают все ресурсы сервера и таким образом снижают производительность веб-сайта.

StateServer

SQL Server является наиболее надежным из всех режимов. Данные сеанса остаются неизменными при перезапуске ASP.NET, а также при перезапуске SQL Server.

SQL Server также является наиболее масштабируемым вариантом.

SQL Server часто доступен в сценарии с общим хостингом

Пользовательский режим

У вас есть полный контроль над сессиями. Можно создать даже пользовательский идентификатор сессии.

Вы можете поддерживать разные источники данных. Это может быть полезно для хранения данных сеанса в другой базе данных, такой как Oracle, MySQL, MS Access и т. Д.

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

Answer 6

1 другим недостатком является то, что у вас, вероятно, будет одна точка отказа, если вы выполните 1 удаленный сервер состояний по всей ферме. Даже если это не ферма, ее все равно стоит запускать локально, чтобы выжить в app_pool IMO. Мы попались на сериализуемую часть, так что смотрите это.

Кроме того, следите за выпуском Windows Server AppFabric, поскольку он будет заменен реплицированным / распределенным сервером состояний. Предположительно RTM в 1П2010.