Почему общее кэширование Windows Azure работает так медленно?

В настоящее время мы находимся в процессе переноса наших серверов на Windows Azure и хотим воспользоваться преимуществами общего кэширования Windows Azure.

Мы написали провайдер для кэширования, так что мы можем включать и выключать его (при необходимости переключаться на кеш времени выполнения), но мы обнаружили, что кеш примерно в 1000 раз медленнее, чем кеш времени выполнения.

Например, возврат объекта веб-сайта из кэша среды выполнения — это общее время 0,0053, где общее время кэширования Azure — 73,6638, а в некоторых случаях — 439,3367.

Не поймите меня неправильно, я ожидаю, что будет небольшая задержка в сети, но это глупо? Это совсем непригодно?

Объект крошечный, общий размер кеша составляет 0,8 МБ, поэтому объект «Веб-сайт» небольшой.

У кого-нибудь есть предложения? Должен ли я использовать метод предварительного просмотра кэширования, который я видел, где он частично выделен? Конечно, у них не было бы этого общего, если бы он был непригоден для использования?

Я видел локальное кэширование, работающее поверх сетевого кэширования, но все же будет ли задержка при локальном перестроении кеша?

Кто-нибудь может дать совет?

Соблюдены следующие условия

Мы работаем с последней версией библиотек Azure DLL.

Мы тестируем веб-сайт, который находится в том же центре обработки данных, что и кэш Azure.

SQL Azure находится в том же центре обработки данных, что и экземпляр, поэтому получение данных не является проблемой.

Я единственный человек, имеющий доступ к этому веб-сайту в настоящее время, поэтому я не считаю, что параллелизм является проблемой.


azure .net azure-caching distributed-caching
person Chris Lomax    schedule 02.10.2012    source источник
comment
Поставщик является поставщиком для Azure. Это просто механизм для быстрого переключения между Azure и кэшем среды выполнения. У нас есть клиенты, у которых нет доступа к кэшу Azure, поэтому мы устанавливаем параметр конфигурации, чтобы включать и выключать его выборочно.   -  person Chris Lomax    schedule 03.10.2012
comment
Извините, я думаю, вы неправильно поняли. Я использую общее кэширование Azure. В этом примере я использую не хранилище BLOB-объектов или хранилище таблиц, а их версию AppFabric. Не знаю, поможет ли это?   -  person Chris Lomax    schedule 03.10.2012
comment
Спасибо, я не думаю, что у меня что-то получится, если честно. Сейчас я прибегнул к настройке двух выделенных экземпляров для кэширования. Что меня раздражает, так это то, что у меня есть настройка memcache на двух машинах в нашей текущей конфигурации, и я написал класс для реализации AppFabric, поскольку у них есть доступная служба, и это выглядит просто чушью! У них есть полувыделенная веб-роль кеша, но она специфична для веб-работника и настройки ролей. Я использую виртуальные машины и не могу найти документацию по подключению к ней! Радости работы с технологиями все еще находятся в режиме предварительного просмотра. Все равно спасибо, Крис   -  person Chris Lomax    schedule 03.10.2012
comment
Я просто удалю свои комментарии, так как они не будут представлять никакой ценности для других.   -  person paparazzo    schedule 03.10.2012
comment
Для тех, кто заинтересован в результате. Я не мог заставить общее кэширование работать быстрее, пока не включил локальное кэширование. Это кеш с тайм-аутом, поэтому он реактивный, а не упреждающий. Упреждающее кэширование недоступно в Shared Caching, поэтому в итоге было развернуто два выделенных экземпляра кэша с полным кэшированием AppFabric. На самом деле получается дешевле за ГБ хранилища без ограничений, вам просто нужно настроить его самостоятельно.   -  person Chris Lomax    schedule 03.10.2012
comment
Использование Preview Cache — это путь вперед, это то, что MS разработала после оценки всех ограничений Shared Caching.   -  person knightpfhor    schedule 04.10.2012

Ответы (2)


arrow_upward
0
arrow_downward

Приносим извинения за проблемы, с которыми вы столкнулись. Общее кэширование Windows Azure было выпущено ранее и работает в рабочей среде. Это должно дать вам хорошие задержки, если вы развернуты в том же центре обработки данных, что и кэш, который вы подготовили. Какова была ваша топология, где был кеш и откуда вы его нажимали?

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

Вы можете прочитать о поддержке протокола и других шагах здесь:

http://msdn.microsoft.com/en-us/library/windowsazure/hh914167.aspx

По поводу "Я использую виртуальные машины и не могу найти документацию по подключению к ним!" , что ты там пытался сделать ?

person Ankit Sud    schedule 04.10.2012
comment
Привет @Ankit, спасибо за ответ. Кэш находился в том же регионе, что и машины, на которых я работал, но он слишком долго отвечал. Что касается проблемы с виртуальной машиной, я запустил предварительную настройку кэширования Azure на основе инструкций и попытался использовать следующий код в своем файле web.config. <dataCacheClients> <tracing sinkType="DiagnosticSink" traceLevel="Error" /> <dataCacheClient name="default"> <autoDiscover isEnabled="true" identifier="WebRole1" /> </dataCacheClient> </dataCacheClients> Это не сработало, так как не удалось найти роли кэширования Azure? - person Chris Lomax; 10.10.2012
comment
С точки зрения моей топологии, было две виртуальные машины, которые обращались к кешу внутри. Я попробовал это локально, но могу смириться с тем, что в этой настройке будет большая задержка. Я также хотел использовать уведомления, которые в любом случае нуждались бы в более специальной настройке. Я также смотрю на Redis, так как я все еще не получаю той пропускной способности, которую хотел. В настоящее время мы используем RuntimeCache и хотели, чтобы он распространялся, и я был готов принять небольшие задержки, но время задержки, похоже, все еще довольно велико. Возможно, нам нужно пересмотреть часть нашего кода и хранить в кеше отдельные элементы, а не объекты. - person Chris Lomax; 10.10.2012

arrow_upward
0
arrow_downward

" "

Вы поставили галочку напротив включения кэширования в свойствах роли? Где произошел сбой клиента (в стеке)?

Что касается времени задержки, какие значения вы видите в выделенном кэшировании, его настолько легко настроить, что было бы преступлением не попробовать :)

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

Если вы пробуете сценарий memcache, это также может быть полезно:

http://blogs.msdn.com/b/silverlining/archive/2012/10/09/using-memcache-to-access-a-windows-azure-dedicated-cache.aspx

person Ankit Sud    schedule 17.10.2012