Прежде чем я начну использовать сервер состояния сеанса, чтобы сделать сессионное состояние более надежным в моих приложениях по сравнению с состоянием InProc, я хотел бы найти список "за" и "против" для оценки.
Обновление 1. Также повторяется перезапуск пула приложений?
Обновление 2. Как насчет продолжительности сеансов и их окончаний?
Вот канонический анализ плюсов и минусов ваших трех вариантов, от Роба Говарда Состояние сеанса ASP.NET:
В процессе. В процессе будет работать лучше всего, потому что память состояния сеанса хранится в процессе ASP.NET. Для веб-приложений, размещенных на одном сервере, приложения, в которых пользователь должен быть перенаправлен на правильный сервер, или когда данные состояния сеанса не являются критическими (в том смысле, что они могут быть перестроены или повторно заполнены), это режим для выбора.
Вне процесса. Этот режим лучше всего использовать, когда производительность важна, но вы не можете гарантировать, на каком сервере пользователь будет запрашивать приложение. В режиме вне процесса вы получаете производительность чтения из памяти и надежность отдельного процесса, который управляет состоянием для всех серверов.
SQL Server. Этот режим лучше всего использовать, когда надежность данных имеет фундаментальное значение для стабильности приложения, поскольку база данных может быть сгруппирована для сценариев сбоев. Производительность не такая высокая, как вне процесса, но компромисс - это более высокий уровень надежности.
Параметры вне процесса (так называемые "StateServer" ) и SQL-Server перезапускают веб-приложение (включая циклирование пула приложений), и оба делают данные сеанса доступными для нескольких серверов в кластере/ферме.
Наконец, это может быть само собой разумеющимся, но базовая настройка в процессе - это самая простая настройка, которая является значимым "про" во многих средах.
Tim Sneath Состояние сеанса ASP.NET: соображения архитектуры и производительности добавляет дополнительную информацию, а Тема MSDN в режимах состояния сеанса является надежным и актуальным источником.
State Server - отличный выбор (!) для начала работы. Зачем? Потому что это означает, что ваше приложение теперь совместимо с любыми режимами хранения вне процесса.
Если вы в настоящее время разрабатываете свой сайт с помощью InProc и хотите позже перейти в StateServer или SqlServer, у вас могут возникнуть проблемы с сериализацией. Не всегда, но это происходит.
Некоторые примеры включают (некоторые уже упомянутые):
Поэтому лучше всего это разобраться раньше, чем позже. Его только изменение конфигурации и запуск службы; Boom!
Что также означает, что если вы решите пойти по совершенно другому пути хранения сеанса, например, используя Redis (Distributed Key/Value Store) или RavenDB (База данных документов), вы уже отсортированы.
Это действительно хорошая инвестиция в 1 минуту работы. Теперь вы готовы к веб-фермам, балансирам нагрузки и любым другим системам управления сеансами, которые вы решили прототипировать.
Преимущества:
1. Вы можете получить доступ к одному и тому же состоянию сеанса на всех компьютерах.
2. То же состояние сеанса доступно после перезагрузки app_pool.
Недостатки:
1. Медленнее, чем в режиме процесса.
2. Все объекты в состоянии сеанса должны быть сериализованы.
Я бы сказал, что одним из больших недостатков использования In_Proc является то, что состояние сеанса может быть потеряно, если пул приложений или домен переработаны. Это может произойти в любое время, например, если на сервере мало памяти и т.д. Я лично никогда не полагаюсь на сеанс In_Proc для всего, что вы не хотите потерять. Я потратил несколько часов на отладку сайтов со спорадическими проблемами только для того, чтобы найти, что это связано с тем, что состояние сеанса было потеряно из-за сервера, который был неактивен при утилизации ресурсов (и, конечно же, чем больше вы храните в сеансе, тем меньше ресурсов сервера, Помните, если он может пойти не так, значит, в какой-то момент он, вероятно, пойдет не так!
Вот почему я теперь обычно использую State Server для чего угодно, кроме тривиальных данных сеанса. Единственный реальный недостаток, который я нашел, - это то, что вам нужно пометить классы как сериализуемые, но это обычно тривиально. Это также немного медленнее, но в большинстве случаев это незначительно.
Там хорошая статья об этом в блоге MSDN IIS.
Недостатки сеансов в ASP.NET
Каждая переменная хранится как объект. Это означает, что вам нужно преобразовать объект в определенный тип при чтении переменной сеанса.
В дополнение к этому, если сеанс пуст, Object будет null. Перед чтением переменной сеанса вам нужно проверить его на null. Даже если переменная инициализирована до этого, она может быть нулевой, поскольку срок действия сеанса истек. Попытка использовать значение null session может вернуть исключение. Если значение переменной сеанса равно null, обычной практикой является использование значения по умолчанию вместо бессмысленного нуля. Если значение не равно null, вы должны преобразовать его в соответствующий тип, потому что все переменные сеанса являются типом объекта. Когда все это, вы должны обратить внимание, чтобы избежать жесткого кодирования. Подробнее о чтении и записи переменных сеанса по масштабируемому и поддерживаемому способу вы можете прочитать в руководстве "Как писать, читать и удалять сеансовые переменные состояния".
Имя переменной - это тип строки. Если у вас жесткое кодовое имя переменной, есть возможность сделать ошибку типа где-то. Проблема в том, что если вы попытаетесь прочитать переменную сеанса, которой не существует, ASP.NET не вернет никаких исключений или предупреждений. Он просто создаст новую переменную с неправильным именем, которое имеет нулевое значение. Эти типы ошибок могут быть трудно найти.
Данные сеанса не должны использоваться для хранения конфиденциальных данных. Существует вероятность того, что злоумышленник получит обычный идентификатор сеанса посетителя. Если состояние сеанса используется для хранения информации типа "разрешить доступ к области администрирования или нет" или что-то в этом роде, злоумышленник может видеть данные, относящиеся к веб-сайту, другие личные данные, редактировать базу данных, удалять контент и т.д.
Если используется режим InProc, сеансы легко исчерпывают все ресурсы сервера и, следовательно, уменьшают производительность веб-сайта.
StateServer
SQL Server является самым надежным из всех режимов. Данные сеанса остаются нетронутыми, если перезагрузка ASP.NET, но также и перезагрузка SQL Server.
SQL Server также является наиболее масштабируемой.
SQL Server часто доступен в режиме совместного хостинга
Пользовательский режим
У вас есть полный контроль над сеансами. Можно создать даже пользовательский идентификатор сеанса.
Вы можете поддерживать разные источники данных. Это может быть полезно для хранения данных сеанса в другой базе данных, таких как Oracle, MySQL, MS Access и т.д.
для любых других деталей вы можете щелкнуть здесь, чтобы просмотреть преимущества состояния сеанса ASP.NET. надеюсь, мой ответ помог вам!:)
Также обратите внимание на выпуск Windows Server AppFabric, поскольку он будет иметь замену реплицированного/распределенного государственного сервера. Предположительно RTM в 1П2010.