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

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

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

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

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

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

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


asp.net session-state web-farm
person Mitchel Sellers    schedule 26.03.2009    source источник
comment
Сколько информации хранится в состояниях сеанса?   -  person Keltex    schedule 26.03.2009
comment
Прямо сейчас мы понятия не имеем. Существует более 150 различных приложений, разработанных разными группами.   -  person Mitchel Sellers    schedule 27.03.2009

Ответы (6)


arrow_upward
23
arrow_downward

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

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

  • В веб-ферме убедитесь, что у вас одинаковый MachineKey на всех веб-серверах. См. KB 313091 о том, как это сделать.
  • Также убедитесь, что ваши объекты сериализуемы. Подробнее см. KB 312112.
  • Чтобы состояние сеанса поддерживалось на разных веб-серверах веб-фермы, путь к приложению веб-сайта (например, \ LM \ W3SVC \ 2) в метабазе IIS должен быть идентичным на всех веб-серверах веб-фермы. Подробнее см. KB 325056.
person AaronS    schedule 26.03.2009
comment
Последний пункт о пути IIS интересен, кто-нибудь знает, применимо ли это еще в IIS7 +? Кроме того, как вы можете проверить этот путь в IIS7? - person Rob Bird; 28.05.2012
comment
Да, это все еще применимо. См. этот ответ на serverfault подробнее. - person Oliver; 15.06.2012
comment
Ты жжешь. Моя проблема была в пути приложения, иначе ID не совпадает. Забавно, как я столкнулся с этой проблемой много лет назад, забыл о ней, и отладка странной аномалии сеанса привела меня сюда. Большое спасибо! - person Doug S; 17.11.2012
comment
+1 для пути к приложению, корпус на двух моих серверах был разным - person Diego; 14.10.2014

arrow_upward
3
arrow_downward

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

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

arrow_upward
2
arrow_downward

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

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

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

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

person saasman    schedule 26.03.2009
comment
Проверка кода - это то, что будет сделано, ЕСЛИ мы докажем, что это возможно исправить. База данных - это не узкое место во всей нашей среде, а большая неравномерная нагрузка на веб-серверы. - person Mitchel Sellers; 27.03.2009

arrow_upward
2
arrow_downward

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

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

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

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

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

person SevDer    schedule 02.04.2009
comment
Для тех, кто ищет серверы кеширования, вы также можете попробовать SharedCache / Indexxus ... довольно надежный инструмент для кеширования. - person bbqchickenrobot; 21.06.2010
comment
Для тех, кто ищет более современное решение: Скотт Хансельман прекрасно написал-вверх / a> о том, как настроить недавно выпущенный кэш памяти Velocity, например в качестве сервера состояния сеанса ASP.NET. - person Oliver; 15.06.2012
comment
Мы протестировали службу состояния ASPNet на основе кэша скорости (AKA appfabric), и результаты резко различались. Служба состояния ASPNet превосходит AppFab в огромных количествах (почти на 250% быстрее), а AppFab требует намного больше памяти, и его сложнее настроить в кластере. Не используйте AppFabric для состояния сеанса - person nachonachoman; 08.09.2014

arrow_upward
0
arrow_downward

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

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

person laktak    schedule 26.03.2009
comment
Я вижу, что это старый пост, но каковы были симптомы сбоя службы? Вы только что начали видеть сообщения об ошибке недопустимого состояния сеанса или это было более загадочно? - person Ads; 01.05.2015
comment
@Ads извините, я не помню, но я думаю, что он просто разбился. - person laktak; 05.05.2015

arrow_upward
0
arrow_downward

Хотел бы еще одно замечание к принятому ответу:

  • Убедитесь, что версия dll фреймворка такая же.

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

person Amol    schedule 09.04.2013