Альтернативы состоянию сеанса HTTP в обычном приложении веб-служб .NET

После долгой борьбы с жизненным циклом страницы в ASP.NET и его производительностью мы начали рефакторинг нашего веб-приложения для реализации веб-сервисов (plain-vanilla .asmx. NET) и jQuery на стороне клиента. ПРИМЕЧАНИЕ: это никоим образом не реализует MVC или ASP.NET, это просто веб-службы.

В обоих вариантах приложения мы генерируем весь контент динамически на одной странице. В распределении ASP.NET это означало (из-за жизненного цикла страницы), что всю страницу нужно было разрушать и перестраивать (почти) при каждом вызове AJAX или изменении веб-формы. Это представляло огромную проблему масштабируемости для приложения, предназначенного для обслуживания множества одновременных пользователей. В разделе веб-сервисов / jQuery, мы можем выборочно сосредоточиться только на тех элементах DOM, которые должны отправлять или получать данные на сервер, что означает гораздо меньше запросов и гораздо более быстрое взаимодействие с пользователем.

Первая итерация приложения показала улучшение производительности на порядок величины; однако, поскольку мы начали создавать все больше и больше веб-сервисов, производительность приложения теперь находится на одном уровне с производительностью распределения ASP.NET.

После долгих поисков в Google / поиске души и нагрузочного тестирования стало ясно, что виноват HTTP-сеанс. По сути, каждое чтение (а иногда просто включение сеанса в область метода веб-службы) является блокирующим вызовом, который вызывает задержку в 500 мс. Как только вы знаете, где искать, это хорошо документировано в литературе MSDN. Как реализовано, Сеанс (если используется несколькими веб-службами одним и тем же пользователем) преобразует асинхронные запросы в синхронные запросы с буфером 500 мс. В настоящее время мы смягчаем это, связывая все наши вызовы AJAX как «успешные» события друг друга, делая их синхронными запросами со стороны клиента. Это устраняет задержку в 500 мс, возникающую при запросе чтения на заблокированном объекте сеанса.

Принуждение клиентского приложения к «синхронному» поведению решило многие проблемы с производительностью; однако это лишь временное решение на короткий срок.

Какие существуют жизнеспособные (масштабируемые!) альтернативы сеансу, опять же, имея в виду, что мы не на ASP.NET, MVC или WCF и т. д.? Нашим самым большим препятствием является постоянство нашей коллекции метаданных, которая инициализируется для каждого пользователя при входе в систему. Это самая дорогостоящая операция в приложении (в 10 или более раз), которую мы хотим выполнить только один раз. Сессия предоставила простой способ хоть раз попотеть и никогда не оглядываться назад; но такой подход выглядит менее осуществимым.

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

Есть ли другие решения этой проблемы, которые могут потребовать меньших усилий для реализации?