SQLServer против StateServer для производительности состояния сеанса ASP.NET

Question

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

Учитывая, что приложение работает в веб-ферме, какое решение для состояния сеанса дает наилучшую производительность (SQL Server или StateServer) и, самое главное, почему?

Answer 1

State Server работает быстрее, потому что он хранит данные сеанса в словаре в памяти. SQL Server работает медленнее, потому что он хранится в базе данных, которая сохраняет данные на диск.

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

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

См. Преамбулу в этой статье для подробного объяснения.

Answer 2

Небольшое, но важное замечание: InProc не может использоваться в ферме, как следует из названия, он выполняется в текущем процессе w3wp и не может использоваться в ферме. StateServer - это служба Windows, поэтому скорость использования StateServer зависит от того, насколько быстро работает машина, на которой работает служба сервера состояний, это только память. Конечно, SQL должен записывать и извлекать данные, которые, вероятно, медленнее, чем только память.

С здесь :

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

Answer 3

По этой ссылке: http://www.eggheadcafe.com/articles/20021016.asp

Performance

• InProc - самый быстрый, но чем больше данных сеанса, тем больше памяти потребляется на веб-сервере, и это может повлиять на производительность.

• StateServer - при хранении данных основных типов (например, строка, целое число, и т.д.), в одной тестовой среде это 15% медленнее, чем InProc. Тем не менее, стоимость сериализации / десериализации может повлиять на производительность, если вы храните много объектов. Вы должны сделать тестирование производительности для себя сценарий.

• SQLServer - при хранении данных основных типов (например, строка, целое число, и т.д.), в одной тестовой среде это 25% медленнее, чем InProc. То же предупреждение о сериализация как в StateServer.

Таким образом, кажется, что StateServer немного быстрее, чем SQL Server для хранения состояния сеанса.

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

Answer 4

SQL Server (в памяти) является ответом - доступно в SQL 2014

http://blogs.msdn.com/b/kenkilty/archive/2014/07/03/asp-net-session-state-using-sql-sever-in-memory.aspx