У меня есть личный опыт, но нет контрольных показателей или реальных зарегистрированных показателей, которыми я мог бы поделиться. Сначала мы создали сайт 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. Преимущества скорости доступа определенно не перевешивают необходимость хранения данных в памяти.
person
Joel Etherton
schedule
11.05.2011
