Разрешение сеанса в веб-ферме? Достаточно ли StateServer?

Прежде всего, чтобы дать вам немного информации о текущей среде. У нас есть несколько приложений ASP.NET, все из которых используют сеанс для определенных аспектов. Мы являемся "Load Balanced" на нескольких серверах из-за уровней трафика, однако наша балансировка нагрузки настроена на использование "Sticky Sessions", так как в настоящее время все веб-приложения настроены на использование "InProc" для состояния сеанса.

Мы смотрим на возможность удалить конфигурацию "Sticky Sessions" на нашем балансировщике нагрузки, поскольку из-за наших загрузок трафика серверы могут и могут перегружаться. Мы хотим использовать более сбалансированный подход, но должны иметь возможность использовать сеанс.

Я знаю, что SqlServer для состояния сеанса будет работать, но по причинам, не зависящим от нашего контроля, мы не можем использовать SqlServer для хранения нашего состояния. При исследовании кажется, что StateServer - наш лучший выбор. У нас есть дополнительный сервер, на котором сидит много памяти. Этот сервер может быть нашим StateServer для всего веб-кластера. Мы просто хотим знать следующее.

1.) Помимо любых возможных проблем с сериализацией с переключением с InProc на StateServer, существуют ли какие-либо важные известные проблемы с потерями объектов сеанса или генерирование ошибок в вышеперечисленной среде?

2.) Помимо единственной точки отказа и более медленной производительности, есть еще какие-либо другие проблемы, о которых нам нужно знать с помощью StateServer.

3.) Существуют ли какие-либо показатели, показывающие разницу в производительности между тремя типами хранилища состояний?

Ответ 1

Вот достойный FAQ по состоянию asp.net: http://www.eggheadcafe.com/articles/20021016.asp

Из этой статьи, вот некоторая информация о StateServer:

В веб-ферме убедитесь, что у вас есть тот же MachineKey на всех ваших веб-серверах. См. KB 313091 о том, как это сделать.
Также убедитесь, что ваши объекты сериализуемы. Подробнее см. KB 312112.
Для того чтобы состояние сеанса поддерживалось на разных веб-серверах в веб-ферме, путь приложения на веб-сайте (например,\LM\W3SVC\2) в метабазе IIS должен быть идентичным на всех веб-серверах в веб-ферме, Подробнее см. KB 325056

Ответ 2

Я использовал только sql и in-proc. Но эти 3, которые применяются при использовании SQL-сервера, также применяются:

Избегайте хранить слишком много информации в сеансе, так как это влияет как на сериализацию, так и на данные, передаваемые по сети.
Убедитесь, что у вас нет ничего, что зависит от Session_onEnd. Это просто недоступно для сеансов процесса.
Отключить сеанс на страницах, которые его не используют. Это не имеет значения для сеанса в процессе, но из-за процесса это значительно сэкономит вам.

Ответ 3

Убедитесь, что идентификаторы сервера etag синхронизированы в веб-ферме, иначе кэширование в клиентских браузерах будет нарушено.

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

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

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

Ответ 4

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

Я думаю, вы можете исследовать другие продукты, чтобы достичь абсолютного успеха. Свободным вариантом будет Velocity, но он по-прежнему не выпущен. И еще один всеобъемлющий, но проверенный продукт будет (очень дорого) NCache. Это даже поможет в ваших сериализации с меньшими затратами. Если вы используете их API, это будет еще лучший результат.

Взгляните и посмотрите, какой из них лучше всего подходит вам.

О сервере SQL Server, вы скоро умрете, если у вас будет достаточно количества обращений (я полагаю, что у вас уже есть какие-то хиты, которые привели вас к созданию веб-фермы, или вы делаете это только ради избыточности)

Итог: мы оцениваем скорость, потому что NCAchce действительно дорогая. Однако преимущества огромны.

Ответ 5

Мы используем StateServer для очень небольшой веб-фермы с двумя узлами для нескольких сотен пользователей.

Я не несу ответственности за его работу, но я помню только два вопроса за два года, когда услугу пришлось перезапустить, потому что она разбилась.

Ответ 6

Я хотел бы еще раз указать на принятый ответ:

Убедитесь, что версия DLL-модулей одинакова.

В моем случае версии dll System.Web различались, поскольку на одном из серверов фермы было пропущено несколько обновлений Windows.