У меня есть личный опыт, но нет тестов или фактических записанных показателей, которыми можно поделиться. Первоначально мы создали сайт Asp.Net, который хранил в сеансе пользовательский объект большего размера, чем обычно, используя метод InProc. Мы обнаружили, что размер объекта и характер наших библиотек обработки ошибок вызвали 2 нежелательных поведения. Первой была переработка пула приложений через случайные промежутки времени во время процессов. Поскольку процесс w3wp.exe будет перезапускать себя в среднем потоке, он будет по существу выгружать сеанс, и объект будет потерян. Это заставило другой код запустить и восстановить сеанс и увеличило задержку наших транзакций. Мы также обнаружили (хотя это не было страшной проблемой, и я обнаружил только при попытке отладить потерю памяти, которую я только что описал), что размер объекта в сеансе вместе с некоторыми объектами, загружаемыми в библиотеки для самой страницы, может вызвать w3wp.exe для многократного просмотра самой страницы. Для небольших запросов, которые включали только объект сеанса или эти объекты библиотеки, но не оба, не было никакого странного поведения подкачки в процессе.
При переходе от InProc к StateServer мы обнаружили немедленную отдачу от переработки. На самом деле пул реже перерабатывал меньше, и даже когда это происходило, наши объекты сеанса оставались в отдельной памяти. Мы также заметили, что это создало универсальное условие «только библиотека», как описано выше в отношении подкачки, и мы больше не испытывали его (хотя по общему признанию я прекратил проверку после 1 месяца безотказной работы). В то время мы обнаружили очень небольшую задержку доступа к определенным библиотекам фреймворка, но когда мы обновили с 2.0 до 3.5, эти аномалии доступа полностью исчезли. Мы надеемся на подобное поведение, когда скоро обновимся с 3.5 до 4.0.
Была предпринята попытка испытательного сайта, использующего SQLServer в качестве контроллера состояния, и единственной задержкой, которую мы обнаружили, было первоначальное создание / хранение сеанса. Последующие вызовы для обновления / доступа к сеансу в SQL не предоставили реальной разницы с опцией StateServer. У меня нет метрик, но ни в одной из систем не было ничего, что указывало бы на разницу в поведении. Отметки времени имели сопоставимые различия во всех аспектах. Преимущество, которое мы получили, хотя оно и имело редкий потенциал использования, заключалось в том, что мы смогли напрямую связать нашу пользовательскую базу данных с сервером состояний сеанса и напрямую сравнить метки времени, состояния и другие специализированные переменные сеанса. У нас не было реальной необходимости в этой функции, и опция StateServer уже была в полном разгаре на наших производственных серверах, поэтому мы решили оставить ее как есть.
В конце концов, не столько скорость, сколько использование памяти убедило нас выбросить InProc для StateServer. Преимущества скорости доступа определенно не перевешивают необходимость в первую очередь хранить данные в памяти.