Сервер состояния сеанса и пользовательский поставщик состояния сеанса

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

• http://blog.maartenballiauw.be/post/2007/11/ASPNET-load-balancing-and-ASPNET-state-server-%28aspnet_state%29.aspx
• http://blog.maartenballiauw.be/post/2008/01/ASPNET-Session-State-Partitioning.aspx
• http://blog.maartenballiauw.be/post/2008/01/ASPNET-Session-State-Partitioning-using-State-Server-Load-Balancing.aspx

Мои проекты, связанные с сервером состояний:

• http://www.codeproject.com/KB/aspnet/p2pstateserver.aspx (последний код наhttps://github.com/tenor/p2pStateServer)
• http://www.codeproject.com/KB/aspnet/stateserverfailover.aspx

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

Answer 3

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

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

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

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

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

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

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

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

Answer 4

Я бы не советовал использовать состояние сеанса независимо от поставщика.

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

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

Особенно в ASP.NET 4 представление может быть очень управляемым и небольшим.