Мы перемещаем сайт asp.net в Azure Web Role и базу данных Azure Sql. Сайт использует выходной кэш и обычный кэш [xxx] (т. Е. HttpRuntime.Cache). Они теперь хранятся классическим способом в памяти экземпляра веб-роли.Разница в производительности между кешем Azure Redis и кешем вхождения для вывода
Низко висящие фрукты должны сначала начать использовать распределенный кеш для вывода кэширования. Я могу использовать кеш-роль в роли либо в качестве совместного размещения, либо с выделенной ролью кеша, либо в кеше Redis. Оба имеют готовые готовые продукты.
Существуют ли различия в производительности между двумя методами (кеше с совместно расположенными/выделенными) кешами?
Следует учесть, что получение страницы из Redis для каждой pageload на каждом сервере будет быстрее или медленнее, чем составление страницы с нуля на каждом сервере каждые 120 секунд, но между ними просто получить его из локальной памяти?
Что будет лучше масштабироваться, если мы хотим начать кеширование наших собственных данных (например, pocos) в распределенном кеше вместо HttpRuntime.Cache?
-Mathias
Tha nks для ответа. Я пошел вперед и начал использовать кеш Azure Redis и outputcacheprovider из StackExchange.Redis. Скорость, конечно, отсутствует по сравнению со стандартным входом-proccache. До тех пор, пока Марк Гравелл не добавит 2-уровневый кэш (локальный кеш в памяти с общим центральным кешем redis, включая уведомление об истечении срока действия паба/суб-тайм и т. Д.), «Обещанный» в сообщении блога, объявляющем пакет Redis, есть компромисс. Если я предполагаю, что мое приложение будет использовать только несколько веб-ролей, я получаю выгоду из в-proc outputcache, но когда я начну использовать больше экземпляров, я бы подошел из распределенного кеша. – MathiasR