Разрешение сессии в веб-ферме? Достаточно ли 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

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

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

Answer 3

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

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

Answer 4

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

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

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

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

Answer 5

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

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

Посмотрите, что лучше всего подходит для вас.

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

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

Answer 6

Я хотел бы еще еще один момент принятого ответа:

• Убедитесь, что версия каркасного DLLs то же самое.

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