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

Question

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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

• Убедитесь, что версия Framework библиотеки одинакова.

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

Answer 6

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

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