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

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

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

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

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

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

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

Вот достойный 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. Это просто невозможно для сеансов процесса.
  • Выключите сеанс на страницах, которые его не используют. Это не имеет значения для сеанса в процессе, но из-за процесса это сэкономит вам много.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Давайте будем гением компьютера.