Разрешить сеанс в веб-ферме? Достаточно ли хорош StateServer?
Прежде всего, чтобы дать вам представление о текущей среде. У нас есть несколько приложений ASP.NET, каждый из которых использует сессию для определенных аспектов. Мы "Балансируем нагрузку" на нескольких серверах из-за уровней трафика, однако наша балансировка нагрузки настроена на использование "Sticky Sessions", так как в настоящее время все веб-приложения настроены на использование "InProc" для состояния сеанса.
Мы рассматриваем возможность удаления конфигурации "Sticky Sessions" на нашем балансировщике нагрузки, поскольку из-за нагрузки трафика серверы могут перегружаться. Мы хотим придерживаться более сбалансированного подхода, но должны иметь возможность использовать сессию.
Я знаю, что SqlServer для состояния сеанса будет работать, но по независящим от нас причинам мы не можем использовать SqlServer для хранения нашего состояния. При исследовании кажется, что StateServer - наш лучший выбор. У нас есть дополнительный сервер с множеством памяти. Этот сервер может быть нашим StateServer для всего веб-кластера. Мы просто хотим знать следующие вещи.
1.) Помимо каких-либо потенциальных проблем сериализации при переходе с InProc на StateServer, существуют ли какие-либо основные известные проблемы с потерей объектов сеанса или генерацией ошибок в вышеупомянутой среде?
2.) Помимо единой точки отказа и чуть более медленной производительности, существуют ли другие ошибки, о которых нам нужно знать при использовании StateServer.
3.) Существуют ли какие-либо показатели, показывающие различия в производительности между тремя типами хранилищ состояний?
6 ответов
Вот достойный FAQ по состоянию asp.net: http://www.eggheadcafe.com/articles/20021016.asp
Из этой статьи, вот некоторая информация о StateServer:
- В веб-ферме убедитесь, что у вас одинаковый MachineKey на всех ваших веб-серверах. См. KB 313091 о том, как это сделать.
- Также убедитесь, что ваши объекты сериализуемы. См. KB 312112 для подробной информации.
- Чтобы поддерживать состояние сеанса на разных веб-серверах в веб-ферме, путь приложения веб-сайта (например, \LM\W3SVC\2) в метабазе IIS должен быть одинаковым на всех веб-серверах в веб-ферме. См. KB 325056 для деталей
Я использовал только sql и in-proc. Но эти 3, которые применяются при использовании сервера sql, также применимы:
- Избегайте хранения слишком большого количества информации в сеансе, поскольку это влияет как на сериализацию, так и на данные, передаваемые по сети.
- Убедитесь, что у вас нет ничего, что зависит от Session_onEnd. Это просто недоступно для сеансов вне процесса.
- Выключите сеанс на страницах, которые его не используют. Это не имеет значения для внутрипроцессного сеанса, но для вне процесса это сэкономит вам много.
Из моего опыта мы узнали, что собственный сервер состояний или даже использование SQL Server для сессий - очень страшный сценарий, поскольку у обоих есть проблемы (в основном, с производительностью). Кстати, мы также используем липкие сессии.
Я думаю, что вы можете исследовать другие продукты, чтобы достичь абсолютного лучшего. Свободным вариантом будет Velocity, но он все еще не выпущен. И еще одним всеобъемлющим, но проверенным продуктом будет (очень дорогой) NCache. Это даже поможет в ваших сериализациях с меньшими затратами. Если вы используете их API, это будет еще лучше.
Посмотрите и посмотрите, что выглядит лучше для вас.
Что касается SQL Server, ваш сервер очень скоро умрет, если у вас будет достаточное количество обращений (я полагаю, что у вас уже есть несколько обращений, которые привели вас к веб-ферме или вы делаете это просто ради избыточности)
Итог: мы оцениваем скорость, потому что NCAchce действительно дорогой. Однако преимущества огромны.
Убедитесь, что etag-идентификаторы вашего сервера синхронизированы по всей веб-ферме, иначе кэширование в клиентских браузерах будет нарушено.
Вы подробно рассмотрели свой код, чтобы убедиться, что все может быть сериализовано вне процесса и эффективно по локальной сети?
Вы решаете основную проблему производительности в вашей системе? Я спрашиваю, потому что база данных является типичным источником разногласий.
Моей основной мотивацией для отказа от липких сессий была оперативная гибкость, то есть отключение проблемного сервера или развертывание обновления программного обеспечения. Поэтому, внедрив центральную службу состояния сеанса, убедитесь, что вы используете все преимущества с точки зрения эксплуатации.
Мы используем StateServer для очень маленькой веб-фермы с двумя узлами для нескольких сотен пользователей.
Я не несу ответственности за его работу, но я помню только два вопроса за два года, когда служба должна была быть перезапущена из-за сбоя.
Я хотел бы еще один момент указать на принятый ответ:
- Убедитесь, что версия фреймворка dll одинакова.
В моем случае версии dll System.Web отличались, так как некоторые обновления Windows были пропущены на одном из серверов фермы.