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

Question

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

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

Обновление 2: А как долговечность сеансов и их окончаний?

Answer 1

Вот канонический анализ плюсов и минусов ваших трех вариантов, из ASP.NET Session State статьи Роб Ховард:

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

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

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

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

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

Тим Снейт ASP.NET Session State: Architectural and Performance Considerations добавляет дополнительную информацию, а MSDN topic on Session State Modes - это надежный, современный источник.

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

Там в a good article about this на блоге IIS MSDN.

Answer 5

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

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

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

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

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

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

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

Answer 6

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

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

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

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

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

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

StateServer

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

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

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

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

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

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

для любых других деталей вы можете click here to view ASP.NET Session state advantages. надеюсь, мой ответ помог вам! :)