2014-10-10 4 views
3

Мы перемещаем сайт asp.net в Azure Web Role и базу данных Azure Sql. Сайт использует выходной кэш и обычный кэш [xxx] (т. Е. HttpRuntime.Cache). Они теперь хранятся классическим способом в памяти экземпляра веб-роли.Разница в производительности между кешем Azure Redis и кешем вхождения для вывода

Низко висящие фрукты должны сначала начать использовать распределенный кеш для вывода кэширования. Я могу использовать кеш-роль в роли либо в качестве совместного размещения, либо с выделенной ролью кеша, либо в кеше Redis. Оба имеют готовые готовые продукты.

Существуют ли различия в производительности между двумя методами (кеше с совместно расположенными/выделенными) кешами?

Следует учесть, что получение страницы из Redis для каждой pageload на каждом сервере будет быстрее или медленнее, чем составление страницы с нуля на каждом сервере каждые 120 секунд, но между ними просто получить его из локальной памяти?

Что будет лучше масштабироваться, если мы хотим начать кеширование наших собственных данных (например, pocos) в распределенном кеше вместо HttpRuntime.Cache?

-Mathias

ответ

9

Отвечая на ваш вопрос, каждый по отдельности:

Есть ли разница в производительности между этими двумя (тя с совместно расположенным/выделенными) методами кэширования?

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

Одна вещь, чтобы рассмотреть, что будет получать страницу с Redis для каждый Pageload на каждом сервере будет быстрее или медленнее, чем составляя страницу с нуля один каждый сервер каждые 120 секунд, но между ними просто получить его от местного Память?

Это будет зависеть от количества объектов на странице, т.е. времени, затраченного на создание страницы с нуля. Хотя получение из кеша будет включать время отключения сети, но в основном в доли секунды.

Какой будет масштабироваться лучше, когда мы хотим начать кэширование наши собственные данные (т.е. Pocos) в распределенной кэш-памяти вместо HttpRuntime.Cache?

Поскольку HttpRuntime.Cache находится в процессе кэширования, он ограничен памятью одного процесса, поэтому он не масштабируется. Распределенный кеш, с другой стороны, является масштабируемым решением, в котором вы всегда можете добавить больше серверов для увеличения объема и пропускной способности кеша. Кроме того, внепроцессный характер решения распределенного кеша позволяет получить доступ к кэшированным данным по процессу приложения, который будет использоваться любым другим процессом.

Вы также можете посмотреть NCache for Azure в качестве распределенного кэширования. NCache является родным .Net распределенным кэшированием.

После сообщений в блоге Икбал Хан поможет вам лучше понять необходимость распределенного кэша для приложений ASP.Net:

Я надеюсь, что это помогает :-)

-Sameer

+0

Tha nks для ответа. Я пошел вперед и начал использовать кеш Azure Redis и outputcacheprovider из StackExchange.Redis. Скорость, конечно, отсутствует по сравнению со стандартным входом-proccache. До тех пор, пока Марк Гравелл не добавит 2-уровневый кэш (локальный кеш в памяти с общим центральным кешем redis, включая уведомление об истечении срока действия паба/суб-тайм и т. Д.), «Обещанный» в сообщении блога, объявляющем пакет Redis, есть компромисс. Если я предполагаю, что мое приложение будет использовать только несколько веб-ролей, я получаю выгоду из в-proc outputcache, но когда я начну использовать больше экземпляров, я бы подошел из распределенного кеша. – MathiasR