Какое лучшее решение для хранения переменных сеанса ASP.NET? StateServer или SQLServer? - PullRequest
8 голосов
/ 22 октября 2008

StateServer или SQLServer?

  • Какое лучшее решение для хранения переменных сеанса ASP.NET?
  • Каковы плюсы и минусы каждого?
  • Является ли один лучше других в какой-то конкретной ситуации?

Ответы [ 6 ]

11 голосов
/ 19 апреля 2009

Вот некоторые мысли о плюсах и минусах. Я также добавил решение Microsoft Velocity Distributed Caching.

Плюсы для InProc

  • Самый быстрый необязательный доступ (все в памяти / оперативной памяти)
  • Простота установки (в файле .config ничего нового не требуется. Я думаю, что это поведение по умолчанию).
  • Большинство людей, которым я верю, используют это.

Минусы для InProc

  • Если веб-сайт (пул приложений) умирает, вся информация о сеансе теряется.
  • Не работает в сценарии WebFarm -> информация о сеансе только для пула приложений.
  • Не может содержать несессионную информацию.

Pro для StateServer

  • В памяти / оперативной памяти, поэтому он быстрый (но имеет некоторую задержку в сети .. читайте ниже), поэтому он может быть не таким быстрым, как Inproc.
  • Конфигурация по умолчанию для сценария веб-фермы. Несколько сайтов iis используют сервер состояний для управления информацией о состоянии сеанса.

Con's для StateServer

  • Требуется настроить службу ASP.NET StateServer.
  • StateServer требуется некоторая настройка конфигурации для приема запросов «удаленного компьютера iis».
  • Существует небольшая крошечная сетевая задержка, если запрос iis должен получить / установить информацию о сеансе на другом сетевом компьютере.
  • Не может содержать несессионную информацию.

Pro для SqlServer (в качестве сервера состояний)

  • Состояние сохраняется всегда, даже после перезапуска сайта iis.

Con's для SqlServer (в качестве сервера состояний)

  • Самое медленное решение -> сетевая задержка И задержка жесткого диска (так как сервер sql сохраняет состояние на жестком диске / читает с жесткого диска).
  • Сложнее всего настроить / настроить.
  • Не может содержать несессионную информацию

Pro для Velocity (или других распределенных систем кэширования)

  • Может обрабатывать не только информацию о сеансе -> объекты, настройки приложения, кэш и т. Д. (Это очень ХОРОШАЯ вещь, ИМО !!)
  • Может быть только памятью или сохраняться в базе данных.
  • Если один «узел» выходит из строя, система все еще работает. (при условии, что есть 2+ узла кэширования)

Con's for Velocity (или другие системы распределенного кэширования)

  • Обычно стоимость $$$
  • Сложнее всего настроить (нужно что-то устанавливать, настраивать конфиги, добавлять дополнительный код):
  • Имеет задержку в сети (которая обычно не равна нулю), но может иметь задержку на жестком диске, если служба сохраняет данные (например, на Sql Server).
3 голосов
/ 22 октября 2008

Я полагаю, что вы используете какую-то веб-ферму.

Одно из применений государственной службы - в веб-саду (несколько рабочих процессов на одном компьютере). В этом случае вы можете использовать балансировку нагрузки, чтобы поддерживать подключение пользователя к определенному серверу, и чтобы все n рабочих процессов совместно использовали одну и ту же службу состояния.

РЕДАКТИРОВАТЬ: В сценарии «веб-сад + служба состояния» или «сервер sql» вы также можете перерабатывать рабочие процессы на этой машине без подключения клиентов, теряющих сеанс.

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

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

И, наконец, существуют сторонние (и некоторые отечественные) распределенные приложения, подобные государственным службам. Некоторые из них имеют преимущества в производительности по сравнению с другими опциями, плюс событие Session_End будет фактически срабатывать. (И при поддержке сеансов как службы состояний, так и SQL Server Session_End в Global.asax не будет запускаться (может быть способ подключения к SQL Server)).

1 голос
/ 22 октября 2008

В многоуровневой среде с состоянием сеанса хоста SQL Server вы создадите дополнительный сетевой трафик для своего бэкэнда, а также потеряете некоторые ресурсы SQL Server, которые теперь должны будут обрабатывать этот дополнительный трафик (сеанс связанные запросы). Управление состоянием SQL Server также выполняется медленнее, чем состояние сервера.

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

0 голосов
/ 09 февраля 2009

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

StateServer сохранил информацию о сеансе на другом компьютере. Веб-ферма может использовать сеанс. Например: несколько рабочих процессов могут получить доступ к информации о сеансе с сервера. Когда время перезагрузки сервера, информация будет потеряна.

SQLServer используется для хранения информации в таблице. По умолчанию он будет храниться в TempDB. Этот tempdb будет динамически вызываться после вызова sqlservice. Так что эти данные также не сохраняются. В этом сценарии мы можем хранить в нашей собственной БД, используя Script, который называется Custom Option.

0 голосов
/ 22 октября 2008

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

0 голосов
/ 22 октября 2008

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

Взгляните на эту статью для быстрого запуска

...