SQLServer по сравнению с StateServer для производительности состояния сеанса ASP.NET
Я только когда-либо пытался оценить это однажды, и это было на 486! Результат был то, что контекстное переключение процессора брало приблизительно 70 инструкций завершиться (обратите внимание, что это происходило для многих вызовов API ОС, а также переключения потока). Мы вычислили, что это брало приблизительно 30us на переключатель потока (включая ОС наверху) на DX3. Несколько тысяч контекстных переключений, которые мы делали в секунду, были абсорбирующими между 5-10% процессорного времени.
, Как это перевело бы в многоядерное, multi-ghz современный процессор, который я не знаю, но я предположил бы, что, если Вы полностью не перебарщивали с переключением потока, это - незначительные издержки.
Примечание, которые распараллеливают создание/удаление, является более дорогим ЦП/ОС hogger, чем активация/деактивация потоков. Хорошая политика для в большой степени потоковых приложений состоит в том, чтобы использовать пулы потоков и активировать/деактивировать как требуется.
3 ответа
Сервер состояний работает быстрее, потому что он хранит данные сеанса в словаре в памяти. SQL Server работает медленнее, потому что он хранится в базе данных, которая сохраняет данные на диске.
SQL-сервер также медленнее, потому что все хранится в одной таблице, что приводит к конфликту, поскольку все больше и больше клиентов получают доступ / обновляют данные сеанса.
SQL-сервер более надежен , поскольку он сохраняется на диске и может быть настроен как кластер с возможностью переключения при отказе.
См. Преамбулу в этой статье для более подробного объяснения. 1124011]
Небольшое, но важное замечание: InProc не может использоваться в ферме, как следует из названия, он работает в текущем процессе w3wp и не может использоваться совместно в ферме. StateServer - это служба Windows, поэтому скорость использования StateServer зависит от того, насколько быстро машина работает, на которой работает служба сервера состояний, это только память. SQL, конечно, должен записывать и извлекать данные, что, вероятно, медленнее, чем только память.
Из здесь :
- В процессе. В процессе будет работать лучше, потому что память состояния сеанса хранится в процессе ASP.NET. Для веб-приложений, размещенных на одном сервере, приложений, в которых пользователь гарантированно будет перенаправлен на правильный сервер или когда данные о состоянии сеанса не являются критическими (в том смысле, что они могут быть переконструированы или повторно заполнены) , это режим, который нужно выбрать.
- Вне обработки. Этот режим лучше всего использовать, когда производительность важна, но вы не можете гарантировать, с какого сервера пользователь запросит приложение. В внепроцессном режиме вы получаете производительность чтения из памяти и надежность отдельного процесса, который управляет состоянием всех серверов.
- SQL Server. Этот режим лучше всего использовать, когда надежность данных имеет основополагающее значение для стабильности приложения, так как база данных может быть кластеризована для сценариев сбоя. Производительность не так высока, как вне процесса, но компромисс - более высокий уровень надежности.
По этой ссылке: http://www.eggheadcafe.com/articles/20021016.asp
Производительность
InProc - Самый быстрый, но чем больше данных сеанса, тем больше памяти потребляется на веб-сервере, и это может повлиять на производительность.
StateServer - При хранении данных основных типов (например, строковых, целочисленных, и т.д.), в одной тестовой среде это 15% медленнее, чем InProc. Однако стоимость сериализации / десериализации может влияют на производительность, если вы храните лоты объектов. Вы должны провести тестирование производительности самостоятельно сценарий.
SQLServer - При хранении данных основных типов (например, строковых, целочисленных, и т.д.), в одной тестовой среде это 25% медленнее, чем InProc. То же предупреждение о сериализация, как в StateServer.
Таким образом, может показаться, что StateServer немного быстрее, чем SQL Server для хранения состояния сеанса.
С точки зрения причины, я бы предположил, что SQL Server более универсален и будет вероятно, будет использоваться и для других целей. Не только это, но и механизм хранения на диске, где, поскольку StateServer работает в отдельном процессе, он просто сохраняет данные в пространстве памяти другого процесса, а не записывает их на диск (если позволяет виртуальная память).