Может ли кто-нибудь сказать мне, что тип поведения, описанный в дампе памяти из Visual Studio, 
Это нормально? например, работает ли StackExchange.Redis.PhysicalConnection так высоко при включенном размере (байтах)? Или это действительно много?
В основном мы испытываем медленную работу веб-головы после преобразования нашего кода для работы в Azure Redis из сеанса (теперь мы сериализуем и десериализуем по мере необходимости и сохраняем в кеше Redis), но общая производительность ужасна.
Запросы выполняются, но это может занять некоторое время, это связано с однопоточным характером Redis? Мы используем конфигурацию, указанную в качестве передовой практики командой Azure Redis, как указано здесь https://stackoverflow.com/a/28821220
На что еще мы можем обратить внимание, чтобы повысить производительность, поскольку текущая производительность неприемлема в качестве жизнеспособной замены нашей реализации на основе сеансов (asp.net webforms / sql server / azure IaaS), которая у нас есть.
PS - Сериализация и десериализация действительно вызывают хит, мы понимаем, что IIS испортил нас своим собственным специальным пулом памяти для несериализованных наборов данных и т. Д., Но нет никакого способа, чтобы это могло вызвать увеличение загрузки страниц на 300-500% теперь для нас.
Мысли оценил!
@ Тим Виман
Насколько велики ваши кэшированные объекты? Они могут различаться по размеру, некоторые наборы данных хранятся в redis.
Что это за типы объектов? Большинство объектов представляют собой настраиваемые объекты с переменным числом свойств, некоторые даже содержат коллекции.
Какой сериализатор вы используете? Мы используем Newtonsoft для всего, что не требует Rowstate и необходимого двоичного сериализатора для наборов данных, которым действительно требуется rowstate.
Вся сериализация и последующая десериализация выполняется в коде перед вызовом Redis баз данных StringGet или StringSet.
