EnableSessionState = ReadOnly - возможные побочные эффекты?

Question

У нас есть довольно большое веб-решение, которое работает на .Net 4.5. В последнее время, когда мы рассматривали проблему с производительностью, когда система, казалось, обслуживала только один запрос в любой момент времени (на каждого клиента), мы узнали, что причиной этого является состояние сеанса. Изменяя атрибут EnableSessionState на ReadOnly, можно одновременно обслуживать несколько запросов, а производительность значительно улучшилась.

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

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

Answer 1

Еще только 62 просмотра?

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

Перейти вперед :-)

Answer 2

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

Однако с завершением сеанса он может распределять циклы ЦП лучше для каждой сессии и нести основную тяжесть другого тяжелого сеанса. Это было нашим наблюдением.