Сервер состояний сеанса против настраиваемого поставщика состояний сеанса

Мне было поручено масштабировать сеанс для приложения. Из моих исследований наиболее очевидным выбором является использование поставщика сеанса State Server, потому что мне не нужно, чтобы сеансы пользователей сохранялись (поставщик сеансов SQL Server)

О приложении:

  • В настоящее время используется поставщик сеанса InProc
  • Все объекты, хранящиеся в сеансе, сериализуемы
  • Все объекты небольшие (в основном простые объекты (int, string) и несколько простых экземпляров классов)

Прежде чем я углублюсь в ИТ-сторону вещей и с возможностью предоставить настраиваемого поставщика сеансов с ASP.NET 4, стоит ли мне хотя бы подумать о настраиваемом поставщике состояния сеанса. Почему или почему нет? Есть ли там «хорошие»?

Спасибо! Отзывы пользователей:

  • Почему мы используем сеанс: сохранение данных между обратными передачами (например, выбор пользователя)
  • Как: пользователь делает выбор, выбор сохраняется. Пользователь покидает страницу и возвращается, выбор восстанавливается. и т. д. и т. д.
  • Будет создавать веб-ферму

architecture c# asp.net session asp.net-4.0
person O.O    schedule 14.01.2011    source источник
comment
Трудно ответить, не зная почему и как вы используете сеанс, но также учитывайте Server AppFabric (ранее Velocity).   -  person Craig Stuntz    schedule 14.01.2011
comment
Что значит как? Я думал, что AppFabric предназначен для кеширования.   -  person O.O    schedule 14.01.2011
comment
Что ж, состояние сеанса - это «кеширование» между обратными передачами.   -  person n8wrl    schedule 14.01.2011
comment
Session - кеш. Он отличается от обычного Cache постольку, поскольку он зависит от пользователя.   -  person Craig Stuntz    schedule 14.01.2011
comment
@Craig - Спасибо за объяснение.   -  person O.O    schedule 14.01.2011

Ответы (4)


arrow_upward
1
arrow_downward

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

Переменные сеанса сериализуются и десериализуются для каждой загрузки отдельной страницы, независимо от того, использует страница эти данные или нет. (РЕДАКТИРОВАТЬ: Крейг указал, что у вас есть некоторый уровень контроля над этим в .net 4 http://msdn.microsoft.com/en-us/library/system.web.sessionstate.sessionstatebehavior.aspx Однако у этого все еще есть недостатки, см. комментарии к этому ответу.)

Для экземпляров с одним сервером это нормально, поскольку вы просто извлекаете его из локальной памяти своего веб-сервера. Нагрузка на эти приложения, как правило, довольно мала, поэтому локальное кэширование пользовательской информации имеет смысл.

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

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

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

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

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

person NotMe    schedule 14.01.2011
comment
Переменные сеанса сериализуются и десериализуются для каждой загрузки отдельной страницы, независимо от того, использует страница эти данные или нет. Это значение по умолчанию, правда, но это неверно как общее утверждение, и если производительность вызывает беспокойство, вы должны явно установить желаемое поведение. См. msdn.microsoft.com/en-us/library / - person Craig Stuntz; 14.01.2011
comment
@Chris: Def. пища для размышлений и кое-что, над чем я размышлял бесчисленное количество раз. Однако, учитывая информацию в моем вопросе, как бы вы «оценили» необходимость сеанса в моем случае? Что вы предлагаете? - person O.O; 14.01.2011
comment
@Craig: Тут две проблемы. Во-первых, это атрибут, который переопределяет унаследованные классы. Таким образом, вы должны установить это для каждой страницы / страницы или контроллера за контроллером. Во-вторых, если он у вас есть, страница по-прежнему будет получать ВСЕ данные сеанса, независимо от того, использовала ли она эти конкретные элементы или нет. - person NotMe; 14.01.2011
comment
@ subt13: я бы сохранил эти выборы в таблице в базе данных. Если предполагается, что он будет сохраняться, это позволит вам контролировать, как долго он действительно сохраняется, и позволит вам сохранить этот выбор даже после выхода из системы. - person NotMe; 14.01.2011
comment
Я не спорю, что делать это правильно - сложно. Помните анекдот: в программном обеспечении есть две сложные проблемы: аннулирование кеша и именование вещей. Но не кэшировать - не всегда приемлемый ответ. - person Craig Stuntz; 14.01.2011
comment
@Chris - Должен признать, что никогда не рассматривал такую ​​возможность. - person O.O; 14.01.2011
comment
@Chris - все ли будет храниться в базе данных или идентификатор сеанса будет храниться на клиенте? - person O.O; 16.01.2011
comment
@ subt13: Если у вас есть какой-то ключ, например идентификатор пользователя, сохраните его в связанной с ним базе данных. Если вы этого не сделаете, отправьте клиенту файл cookie с каким-либо типом сгенерированного идентификатора. У вас даже может быть поле с именем LastAccess, которое обновляется при каждом доступе к данным. Затем вы можете настроить что-нибудь для очистки таблицы, если последний доступ был более недели или около того. - person NotMe; 17.01.2011
comment
@Craig: Я не говорил никогда не кешировать. Однако вы должны точно понимать, какую выгоду, если таковая имеется, вы получаете от выбранного типа кеша. Если вы не получаете никакой пользы, то какой смысл в добавлении этой сложности? - person NotMe; 17.01.2011
comment
@ Крис: Конечно. Это верно в отношении любой оптимизации производительности, не так ли? - person Craig Stuntz; 17.01.2011
comment
Я решил попробовать этот подход. - person O.O; 17.01.2011

arrow_upward
5
arrow_downward

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

Полезные ссылки из блога Маартена Баллиау:

Проекты, связанные с My State Server:

Надеюсь, это поможет.

person tenor    schedule 14.01.2011
comment
Они показались мне полезными, поэтому я включил их в ваш ответ. :) Добро пожаловать в Stack Overflow! - person Craig Stuntz; 14.01.2011
comment
Спасибо, давно скрывался :) - person tenor; 14.01.2011
comment
Отличные ссылки. Особенно первый. Спасибо. - person O.O; 14.01.2011

arrow_upward
5
arrow_downward

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

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

Для максимальной производительности веб-фермы вы также можете попробовать использовать AppFabric, как было предложено ранее. Я сам этого не делал, но объясняется здесь.

Кроме того, вот ссылка для использования Memcached в качестве поставщика состояния сеанса. Опять же, я им не пользовался, поэтому не могу высказать свое мнение по этому поводу ...

РЕДАКТИРОВАТЬ: как @HOCA упоминает в комментариях, есть сторонние решения, если стоимость не является проблемой. Я слышал (но не использовал) это ScaleOut SessionServer.

person blech    schedule 14.01.2011
comment
Сервер состояний также имеет ограничение, заключающееся в невозможности распределять состояние сеанса между несколькими серверами состояний. Хотя поставщик состояния сеанса SQL потенциально может масштабироваться в кластере серверов SQL, его низкая производительность и высокая стоимость делают его менее чем идеальным вариантом. - person HOCA; 14.01.2011
comment
+1 - для веб-фермы необходимо использовать внепроцессное состояние сеанса. В зависимости от вашей существующей инфраструктуры, проще всего начать с настройки состояния SQL. Если загрузка становится слишком высокой для одного SQL, вы можете разделить состояние сеанса между несколькими серверами (используя partitionResolverType - msdn.microsoft.com/en-us/library/h6bb9cz9.aspx). - person Alexei Levenkov; 14.01.2011
comment
В прошлом мы успешно реализовали собственный провайдер состояния сеансов Memcached. Плюсы - скорость и стоимость. Минусом (3 года назад) была надежность. Я уверен, что с тех пор, как мы внедрили его, было много обновлений как для Memcached, так и для его интерфейса .NET, так что этот вариант стоит рассмотреть, если стоимость является проблемой. Если стоимость не вызывает беспокойства, оцените решения сторонних производителей, поскольку они могут обеспечить лучшую надежность и поддержку. - person HOCA; 14.01.2011

arrow_upward
-1
arrow_downward

Я бы не советовал использовать состояние сеанса, независимо от провайдера.

Особенно с вашими «очень маленькими объектами» используйте viewstate. Почему?

  1. Лучше всего весы. НИЧЕГО не нужно помнить на сервере.
  2. НЕ беспокойтесь о тайм-ауте сеанса.
  3. Не беспокойтесь о веб-фермах.
  4. Не беспокойтесь о потраченных впустую ресурсах для сеансов, которые никогда не вернутся.

Состояние просмотра, особенно в ASP.NET 4, может быть очень управляемым и маленьким.

person n8wrl    schedule 14.01.2011
comment
Сессии были созданы не просто так :) Viewstate зависит от страницы. Увеличение viewstate замедляет страницу. Viewstate ненадежен. В остальном я согласен. - person O.O; 14.01.2011
comment
Что вы имеете в виду, что "viewstate ненадежен"? И состояние просмотра, и сеанс были созданы для «имитации» состояния веб-страниц. Я опубликовал только потому, что у меня не было ничего, кроме душевной боли с состоянием сеанса, и все, что вы можете сделать, чтобы этого избежать, было бы хорошо. - person n8wrl; 14.01.2011
comment
Я тоже ненавижу сеанс, но это неизбежное зло. Каждый раз, когда я пытаюсь использовать состояние просмотра, я получаю ошибки. Полагаю, это просто ошибка пользователя. - person O.O; 14.01.2011
comment
Сессия - это просто кеш для конкретного пользователя. Несмотря на то, что люди часто злоупотребляют им, в этом нет ничего принципиально плохого. OTOH, viewstate имеет свои проблемы. - person Craig Stuntz; 14.01.2011
comment
Думаю, -2 уже достаточно ... Хотя в вашем сообщении хорошо сказано об использовании состояния просмотра, он, как правило, не заменяет состояние сеанса. Очень сложно сохранять состояние просмотра по страницам и запросам. Т.е. он теряется при запросах GET и не может использоваться во время переадресации 302. - person Alexei Levenkov; 14.01.2011
comment
@ subt13: Я не согласен с тем, что сессия - это «необходимое» зло. В частности, с необходимой частью. Очень мало случаев, когда значение, предоставляемое сеансом, превышает его проблемы. Если это приложение с ограниченным сроком службы, которое никогда не будет работать более чем на 1 сервере, тогда все в порядке. - person NotMe; 14.01.2011
comment
@Chris - Чтобы прояснить, в контексте моего вопроса это необходимое зло. В других приложениях может и не быть. - person O.O; 14.01.2011
comment
@ subt13: возможно, вы захотите прочитать мой ответ здесь. Все данные, которые вы храните в сеансе, загружаются для каждой страницы, даже для тех, которые не используют эти значения. Это большой трафик, и есть способы получше. - person NotMe; 14.01.2011
comment
Я поставил этому посту +1, потому что он предлагает новую и необычную точку зрения, имеющую свои достоинства - при условии, что у вас есть опыт и вы точно знаете, что делаете. Я думаю, что ваш пост был бы более приемлемым для других, если бы вы сказали, что попробуйте / verify / thinkof / etc вместо императива, не делайте этого. В императивных формах это опасно для начинающих веб-разработчиков. Это все еще важная точка зрения, перефразируйте ее! - person quetzalcoatl; 15.02.2013
comment
@quetzalcoatl: Спасибо за предложение. Я так и сделаю. - person n8wrl; 15.02.2013