Выбираем Windows Azure: планирование емкости службы кэширования Windows Azure Caching

项目
11/07/2012

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

Введение
Методика планирования мощности
Шаг первый: определение узких мест и выбор кандидатов для кэширования
Шаг второй: оценка эффективности текущих шаблонов рабочих нагрузок
Шаг третий: определение бизнес-требований ко всем приложениям
Шаг четвертый: определение параметров конфигурации службы кэширования и возможностей их оптимизации
Шаг пятый: выбор наиболее подходящего способа кэширования
Средство планирования мощности
Мониторинг текущих требований к мощности кэширования

Введение

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

Примечание. В предыдущей версии этого документа рассматривался вопрос планирования мощности локального решения для кэширования с использованием Windows Server AppFabric. Дополнительные сведения см. в документе Руководство по планированию загрузки кэширования AppFabric. Некоторые принципы планирования мощности для кэширования на платформе Windows Azure и для локального кэширования общие, поскольку в их основе лежит одна и та же базовая система. Это значит, что в данных документах часть материала осталась без изменений. При этом необходимо обратить внимание на ряд существенных отличий и использовать руководство, предназначенное для целевой платформы пользователя.

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

В основу этого документа положены результаты планирования, выполненного сотрудниками Microsoft для клиентов. При использовании Windows Azure вам не нужно управлять собственными серверами кэширования или рассчитывать объем памяти для каждого сервера. Эти действия выполняет платформа. Однако вам необходимо выбрать оптимальный вариант кэша. Наиболее очевидное отличие этих вариантов — объем памяти, доступный для кэшированных объектов. При этом каждый из вариантов имеет связанную квоту на количество транзакций, пропускную способность и количество одновременных подключений. Этот документ поможет вам принять наилучшее решение и выбрать оптимальный вариант кэша. Документ содержит практические рекомендации и советы по оптимизации, которые позволят максимально эффективно использовать службу кэширования.

Методика планирования мощности

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

Шаг первый: определение узких мест и выбор кандидатов для кэширования
Шаг второй: оценка эффективности текущих шаблонов рабочих нагрузок
Шаг третий: определение бизнес-требований ко всем приложениям
Шаг четвертый: определение параметров конфигурации службы кэширования и возможностей их оптимизации
Шаг пятый: выбор наиболее подходящего способа кэширования

Рассмотрим эти шаги на примере изучения потребностей приложения интернет-магазина. Один и тот же кэш можно использовать для нескольких приложений Azure. Однако для лучшего разделения приложений рекомендуется применять как минимум один кэш для каждого приложения. Это дает максимальную гибкость в управлении кэшем и позволяет увеличивать его объем по мере роста потребностей приложения.

Шаг первый: определение узких мест и выбор кандидатов для кэширования

Сначала необходимо идентифицировать данные для кэширования. Для этого можно профилировать для тестовой рабочей нагрузки приложение Windows Azure, запущенное на компьютере разработчика. Для локального тестирования можно использовать профилировщик SQL Server Profiler, монитор производительности Performance Monitor, тестировщик Visual Studio и другие средства. Они позволят получить общее представление о наиболее часто вызываемых методах, самой медленной службе, процессах в базе данных и других особенностях рабочей нагрузки. Все эти действия выполняются локально на одном компьютере для разработки. На основе собранных сведений можно смоделировать поведение приложения в условиях реальной нагрузки. Очевидно, что при этом можно получить лишь приблизительную оценку, поскольку приложение не тестируется в облаке и к нему невозможно применить полную нагрузку.

Для получения более точной оценки следует провести диагностику приложений, запущенных в Windows Azure. Существует несколько способов сбора данных из различных экземпляров ролей Azure. Во-первых, можно настроить службу диагностики Windows Azure для анализа журналов IIS, журналов событий Windows, счетчиков производительности и других данных для диагностики. С помощью настраиваемых процессов трассировки и ведения журналов можно инструментировать код для получения сведений о частоте вызовов методов, времени их выполнения и других данных о приложениях. Этот способ дает более точное представление о том, в каких случаях кэширование будет максимально эффективным. Дополнительные сведения о службе диагностики Windows Azure см. в статье Collecting Logging Data by Using Windows Azure Diagnostics (Сбор данных журналов с помощью службы диагностики Windows Azure). Для взаимодействия с экземплярами ролей с целью выполнения задач мониторинга можно использовать удаленный рабочий стол или компонент Windows Azure Connect. Дополнительные сведения см. в статье Windows Azure Tools for Microsoft Visual Studio (Средства Windows Azure для Microsoft Visual Studio). И, наконец, если в решении используется роль виртуальной машины, экземпляр этой роли можно настроить с помощью предустановленных средств мониторинга, которые будут формировать отчеты о производительности приложений, связанных с данной ролью виртуальной машины.

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

После определения кандидатов на кэширование рекомендуется распределить эти объекты по трем основным категориям: Activity data (Данные о действиях) , Reference data (Ссылочные данные) и Resource data (Данные ресурсов) . Поясним это на примерах.

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

Для разных типов кэшированных данных будут действовать разные шаблоны использования, поэтому классификация данных по этим категориям может оказаться весьма полезной. Например, объект идентифицирован как ссылочные данные; это автоматически предполагает, что объект — не просто рабочая нагрузка только для чтения. Это позволяет определить политики срока действия; чем чаще меняются данные, тем короче срок действия. Такие логические разделения указывают на области, которые при разработке можно инкапсулировать в код. Логические разделения также позволяют выявить области, в которых можно использовать отдельные кэши, если максимальный размер текущего кэша (4 ГБ) недостаточен для хранения кэшированных данных приложения. Однако в рассматриваемом примере используется только один кэш.

Рекомендуется оценить отдельные объекты, а затем обобщить данные. В качестве примера приведем таблицу, которая содержит сведения, собранные на этом этапе.

Кэшируемый объект	Классификация кэширования	Место постоянного хранения (пример)
Объект «Корзина для покупок»	Данные о действиях	Нет
Объект «Настройки пользователя»	Данные о действиях	База данных SQL
Каталог продукции	Ссылочные данные	База данных SQL
Цепочка сообщений пользователя на форуме	Данные ресурсов	Хранилище BLOB-объектов Windows Azure

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

Шаг второй: оценка эффективности текущих шаблонов рабочих нагрузок

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

Например, если вы хотите кэшировать каталог продукции, вам нужно понять, когда приложение извлекает данные каталога и установить периодичность этих запросов. На предыдущем этапе было установлено, что каталог продукции относится к ссылочным данным; следовательно, это рабочая нагрузка главным образом только для чтения.

Существует несколько способов анализа текущих шаблонов доступа к данным.

Всестороннее изучение кода для определения мест доступа к данным и частоты доступа.
Использование профилировщика кода (например, из комплекта поставки Visual Studio), который позволяет задать частоту вызовов метода и связанные параметры производительности.
Создание инструментария в коде для конкретных разделов доступа к данным. Регистрация в журнале попыток доступа к данным и связанные параметры производительности при работе с данными.
Использование профилировщика базы данных (например, SQL Server Profiler) для отслеживания количества и продолжительности операций базы данных.

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

На этом этапе мы можем оценить самый важный параметр — среднее количество транзакций в секунду при пиковой нагрузке. Чтобы определить количество транзакций в час, это значение нужно умножить на 60 секунд, а затем на 60 минут. Полученный показатель позволяет определить соответствие квоте транзакций. В таблице приведены собранные на этом этапе образцы данных объекта «Корзина для покупок».

Анализируемый объект	Корзина для покупок
Среднее кол-во транзакций в секунду (пиковая нагрузка)	250
Предполагаемое кол-во транзакций в час (пиковая нагрузка)	900 000

В нашем примере приложению требуется кэш, позволяющий выполнять не менее 900 000 транзакций в час. В настоящее время этому требованию соответствует кэш размером 512 МБ. Для определения квоты пропускной способности важно знать частоту операций; однако для этого необходимы дополнительные данные о размере объекта. Аналогичный анализ следует выполнить для каждого типа объекта. Разные типы объектов будут иметь разные шаблоны доступа и разные значения среднего количества транзакций в секунду при нагрузке.

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

Проведя мониторинг данных веб-приложения ASP.NET, мы определили время высокой загрузки с 700 одновременно работающими пользователями. Каждому пользователю требуются сведения о состоянии сеанса; это 700 кэшированных объектов. Однако в соответствии с настройками приложения, сеанс должен завершиться через 30 минут. Согласно операционным данным, в период высокой загрузки в течение часа могут быть добавлены еще 100 новых пользователей. Другими словами, за время 30-минутного сеанса могут подключиться 100 новых пользователей. Кроме того, некоторые пользователи могут закрыть браузер и запустить новый сеанс. Это те же самые пользователи, но теперь они используют другой сеанс. Это следует учитывать при дополнительном заполнении (100 сеансов). И, наконец, необходимо спланировать ожидаемый рост в течение следующих 6-12 месяцев (10 %, 90 сеансов). Расчет максимального количества активных объектов в кэше может выглядеть следующим образом.

Анализируемый объект	Корзина для покупок
Количество одновременных пользователей в момент пиковой нагрузки	700
Количество новых пользователей в течение сеанса (30 минут)	100
Количество существующих пользователей, запускающих новые сеансы браузера	100
Оценка роста количества пользователей в будущем (10 %)	90
Общее кол-во активных объектов (максимум)	~1000 активных объектов

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

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

Кроме максимального количества объектов в кэше необходимо знать средний размер объекта. Это непростая задача. В примере с корзиной для покупок один пользователь может положить в корзину один элемент, а другой — десять или двадцать элементов. Нам нужно определить среднее значение. Мы не можем определить точное значение этого параметра, как и большинства других параметров. Однако такая примерная оценка станет отправной точкой, позволяющей установить объем памяти, необходимый для кэширования.

Объекты хранятся в кэше в сериализованном виде. Чтобы определить средний размер объекта, нужно вычислить средний размер сериализованного объекта. Сериализованный размер объекта складывается из сериализованного размера ключа объекта и сериализованного размера значения объекта. Можно использовать настраиваемую сериализацию. Однако по умолчанию перед сохранением элементов в кэше служба кэширования использует для сериализации класс NetDataContractSerializer. Чтобы определить средний размер объекта, добавьте в приложение инструментальный код, предназначенный для сериализации объектов и записи сериализованного размера. Этот размер должен состоять из сериализованного размера ключа и сериализованного размера объекта.

В следующем примере кода оценивается средний размер одного объекта. Сериализуемый объект имеет имя obj. Для записи длины используется переменная length. Если не удается определить размер с помощью параметра NetDataContractSerializer, вместо него используется параметр BinaryFormatter. Для упрощения работы его можно поместить в метод. В этом случае объект obj будет передан в качестве параметра, а переменная length будет возвращена из метода.

В качестве альтернативного варианта можно запустить тестовую рабочую нагрузку в кэше. На портале управления Windows Azure можно сравнить количество объектов, добавленных в кэш, с размером кэша. Обычно последние результаты активности кэша отображаются на портале с задержкой в несколько минут.

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

Уделить внимание типу объекта (например, объекту «Корзина для покупок»).
Определить средний размер сериализованного объекта.
Добавить 500 байт к среднему размеру с учетом затрат на кэширование.
Округлить размер каждого объекта до ближайшего значения в килобайтах. Округлить предполагаемый размер объекта до ближайшего значения в килобайтах.
Умножить это значение на максимальное количество активных объектов. Это позволит определить общие требования к памяти для кэширования данного типа объектов.
Повторить описанные выше действия для каждого определенного типа объекта.
Обобщить результаты и определить общие требования к памяти для кэширования.

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

Анализируемый объект	Данные о действиях	Ссылочные данные
Средний размер объекта (постсериализация):	10 240 байт	81 920 байт
Служебные данные для каждого объекта (1 %)	102 байта	819 байт
Откорректированный средний размер объекта	10 342 байта	82 739 байт
Значение, округленное до ближайшего килобайта	11 264 байта	82 944 байта
Макс. кол-во активных объектов	~1000	~1200
Требования к объему памяти для кэширования	10,7 МБ	94,9 МБ

После обобщения этих оценок определяются начальные требования к памяти для кэша. В этом примере итоговое значение составляет 106 МБ. После начальной оценки можно приступить к решению других вопросов, влияющих на окончательное решение: рассмотреть условия соглашения SLA, обеспечить оптимизацию кэширования и соответствие квотам кэширования.

Совет. При проведении оценки необходимо помнить о главной цели использования Windows Azure: о поддержке эластичного масштабирования. В приведенном примере параметры рабочей нагрузки для интернет-магазина можно оценить отдельно для обычных дней и для дней с пиковой нагрузкой. Из этого можно сделать следующий вывод: в течение большей части года следует использовать небольшой объем кэша, который можно увеличить для обработки максимального количества запросов в период пиковой активности покупателей.

Шаг третий: определение бизнес-требований ко всем приложениям

Перед принятием окончательного решения нужно определить бизнес-требования или условия соглашения об уровне обслуживания (SLA). На этом этапе определяется необходимое количество отдельных кэшей.

Например, при наличии критически важного приложения, использующего кэш, может потребоваться изолировать этот кэш от других приложений с более низким приоритетом. Приложения с низким приоритетом могут негативно повлиять на важное приложение. Например, использование другими приложениями чрезмерного объема памяти в кэше может привести к удалению данных из критически важного приложения. Если другие приложения превышают прогнозируемые квоты для транзакций, пропускной способности и подключений, кэш может стать непригодным для использования до тех пор, пока в течение следующего часа квот не будет выполнен сброс квот. Поэтому даже если вы можете использовать один кэш размером 4 ГБ для нескольких приложений, иногда имеет смысл зарегистрироваться с целью получения нескольких отдельно управляемых кэшей.

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

Шаг четвертый: определение параметров конфигурации службы кэширования и возможностей их оптимизации

В таблице перечислены функции службы кэширования и связанные аспекты планирования мощности.

Область	Описание	Влияние
Сжатие	По умолчанию сжатие отключено. При включении сжатия кэшированные элементы сжимаются перед отправкой в кэш и распаковываются при возвращении из кэша.	Сжатые объекты имеют меньший объем; таким образом, средний размер объекта также уменьшится. Сжатие влияет на необходимый общий объем памяти, а также на пропускную способность для того же сценария.
Локальный кэш	Локальный кэш использует память в клиенте кэша для временного локального хранения кэшированных элементов. Элементы возвращаются локально до тех пор, пока не истечет установленное время ожидания. В это время следующий запрос извлекает из кэша обновленный элемент.	При условии, что приложение часто запрашивает в кэше одни и те же ключи, локальный кэш может увеличить производительность приложения за счет предотвращения циклических обращений к кэшу. При этом количество транзакций в кэше может быть значительно сокращено.
Группировка подключений	Группировка подключений позволяет использовать один и тот же набор подключений в любом количестве экземпляров DataCacheFactory для одной и той же конфигурации клиента кэша.	При группировке подключения используются совместно с экземплярами DataCacheFactory, имеющими одну и ту же конфигурацию клиента кэша. В этом случае количество подключений соответствует значению параметра maxConnectionsToServer.
Экземпляры DataCacheFactory	Если группировка подключений отключена, объект DataCacheFactory связывается с открытым подключением к кэшу и используется для возвращения кэша в код. Каждый поставщик ASP.NET использует один объект DataCacheFactory.	Если группировка подключений отключена, количество экземпляров DataCacheFactory влияет на количество подключений к кэшу, необходимых для работы приложения.
Параметр maxConnectionsToServer	Параметр maxConnectionsToServer определяет количество подключений для каждого объекта DataCacheFactory или указывает общее количество подключений в пуле подключений.	Если группировка подключений отключена, увеличение значения параметра maxConnectionsToServer приводит к росту количества подключений к экземплярам DataCacheFactory. Если группировка подключений включена, параметр maxConnectionsToServer указывает общее количество подключений для группировки.

Сжатие

Сжатие можно включить с помощью параметров файла конфигурации или программно присвоить параметру DataCacheFactoryConfiguration.IsCompressionEnabled значение true. В следующем примере показано изменение в файле конфигурации.

<dataCacheClient name="default" isCompressionEnabled="true">

Включение сжатия позволяет снизить требования к памяти и полосе пропускания. Проблема заключается в оценке эффекта сжатия. Например, сжатие файла изображения не приведет к существенному сокращению его размера, в отличие от сжатия текстового файла. Кроме того, необходимо помнить, что байтовые массивы размером менее 1 КБ не сжимаются. Для оценки эффекта сжатия применяются выполняемые вручную тесты или репрезентативные типы объектов. Чтобы оценить эффективность сжатия, ознакомьтесь со следующей статьей, в которой описаны способы сжатия клиента вручную: AppFabric Cache – Compressing at the Client (Кэш AppFabric: сжатие на стороне клиента). Необходимо также определить средний размер объекта. При сжатии это значение будет меньше, чем без сжатия.

Локальный кэш

Локальный кэш используется для хранения извлеченных значений кэша в локальной памяти клиента кэша. Это достигается программной настройкой свойства DataCacheFactoryConfiguration.LocalCacheProperties или с помощью файла конфигурации. В следующем примере показан раздел localCache файла конфигурации приложения.

Использование локального кэша позволяет сократить количество транзакций в целевом кэше. Однако сокращаются только транзакции чтения, которые повторяются в течение срока жизни, определяемого параметром ttlValue. В приведенном выше примере показано, что если один и тот же элемент кэша был прочитан 100 раз в течение 300 секунд, заданных для параметра срока жизни локального кэша, доступ к кэшу получит только первый вызов Get. Все остальные вызовы будут возвращены из локально кэшированного элемента. Улучшение производительности и оптимизация количества транзакций зависит от периодичности повторяющихся операций чтения из кэша и времени использования атрибута ttlValue.

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

Подключения

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

[maxConnectionsToServer setting] * [Azure role instance count]

Примечание. Функция группировки подключений была впервые представлена в выпуске пакета SDK Windows Azure в ноябре 2011 года. Дополнительные сведения об использовании группировки подключений см. в статье Understanding and Managing Connections (Знакомство с подключениями и управление ими).

Если группировка подключений отключена, в зависимости от значения параметра maxConnectionsToServer каждый объект DataCacheFactory использует одно или несколько подключений. Очень важно инициализировать и сохранить экземпляры DataCacheFactory для контроля открытых подключений и достижения максимальной производительности.

Если группировки подключений не используются, количество подключений, необходимое для работы кэша, определяется по следующей формуле:

[DataCacheFactory instances] * [maxConnectionsToServer setting] * [Azure role instance count]

По умолчанию параметру maxConnectionsToServer присвоено значение 1. Обычно это значение не меняется. Вы можете увеличить его, если хотите проверить, повысит ли это производительность приложения. Возможно, установка более высокого значения приведет к повышению производительности при предоставлении общего доступа к объектам DataCacheFactory или DataCache в потоках. Например, если параметр maxConnectionsToServer имеет значение 2, то каждый объект DataCacheFactory использует два подключения. Изменить этот параметр можно программным способом с помощью свойства DataCacheFactoryConfiguration.MaxConnectionsToServer. Этот параметр можно также изменить в файле конфигурации. В следующем примере этому параметру присваивается значение 2 в файле конфигурации.

<dataCacheClient maxConnectionsToServer="2">

В этом примере важное значение имеет количество экземпляров ролей Azure. При наличии трех экземпляров веб-роли, каждый из которых создает объект DataCacheFactory, используется три подключения (предполагается, что maxConnectionsToServer = 1).

Шаг пятый: выбор наиболее подходящего способа кэширования

В примере с веб-приложением ASP.NET следует принять во внимание следующее.

Анализируемый объект	Данные о действиях	Ссылочные данные
Откорректированный средний размер сериализованного объекта	11 КБ	81 КБ
Макс. кол-во активных объектов	~1000	~1200
Требования к общему объему памяти	10,7 МБ	94,9 МБ
Предполагаемое кол-во транзакций в час (пиковая нагрузка)	18 000	28 800
Предполагаемая пропускная способность в час (пиковая нагрузка)	194 МБ	2279 МБ

В следующей таблице приведены обобщенные данные и связанные варианты использования кэша, применяемые с ноября 2011 года. Обратите внимание, что пропускная способность определяется путем умножения количества транзакций в час во время пиковой нагрузки на средний размер объектов. Количество подключений определяется проектом приложения и параметрами развертывания, как описано в предыдущем разделе (в этом примере указано произвольное значение).

Ресурс	Оценка (обобщенное значение)	Вариант использования кэша (ноябрь 2011 г.)
Оперативная память	206 МБ	128 МБ
Транзакции	46 800 транзакций/час	128 МБ
Пропускная способность	2473 МБ/час	256 МБ
Подключения	3	128 МБ

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

Предыдущий шаг имеет важное значение для оптимизации. Рассмотрим тот же сценарий с включенной функцией сжатия. Если в результате сжатия средний размер объекта сокращается на 70 %, новые рассчитанные значения будут следующими.

Ресурс	Оценка (обобщенное значение)	Вариант использования кэша (ноябрь 2011 г.)
Оперативная память	33 МБ	128 МБ
Транзакции	46 800 транзакций/час	128 МБ
Пропускная способность	775 МБ/час	128 МБ
Подключения	3	128 МБ

Сокращение средних размеров объектов с помощью сжатия приводит к снижению необходимой пропускной способности. При этом требуемый размер кэша сокращается с 256 МБ до 128 МБ.

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

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

Средство планирования мощности

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

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

Второй раздел таблицы позволяет выполнять оценки для различных типов объектов. В этой таблице для типов данных «Данные о действиях» и «Ссылочные данные» используются только два раздела. Таблица имеет несколько пустых столбцов. В зависимости от уровня детализации, определенного на этапе планирования (объект, категория, приложение и т. д.) эти столбцы можно переименовать.

Третий раздел позволяет определить требования к сети. Необходимо указать значение параметра Average Transactions per Second (Peak Load) [Предполагаемое кол-во транзакций в час (пиковая нагрузка)]. В этом разделе рассчитываются значения параметров Transactions per hour (Кол-во транзакций в час) и Bandwidth per hour (Пропускная способность в час).

В четвертом разделе определяется количество подключений, необходимое для работы приложения Windows Azure.

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

Мониторинг текущих требований к мощности кэширования

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

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

Первый способ сравнения — использование статистических данных на портале управления Windows Azure. Выберите кэш и перейдите в окно свойств для просмотра значений параметров Current Size (Текущий размер), Peak Size (this month) [Максимальный размер (этот месяц)], и Peak Size (last year) [Максимальный размер (последний год)]. Эти значения не меняются в реальном времени; их обновление может занять пятнадцать и более минут. Если значение текущего или максимального размера близко к размеру предложения кэша, может произойти нежелательное удаление последних использовавшихся элементов при работе кэша. Однако статистика может быть неверной. Если время окончания срока действия добавленных в кэш элементов не указано, по умолчанию задается 48 часов. Рекомендуется всегда указывать оптимальное время окончания срока действия кэшируемых данных, чтобы иметь представление о реальном максимальном размере кэша. Для этого можно использовать перегрузку методов DataCache.Add и DataCache.Put.

Предыдущий способ касается только памяти, однако необходимо также отслеживать транзакции, пропускную способность и подключения. В настоящее время возможность просмотра этих компонентов на портале отсутствует. При превышении одной из квот интерфейс API службы кэширования выведет объект DataCacheException с параметром ErrorCode, имеющим значение DataCacheErrorCode.RetryLater, и параметром SubStatus, имеющим значение DataCacheErrorCode.QuotaExceeded. Все исключения необходимо зарегистрировать в журнале с помощью службы диагностики Windows Azure. В подобных отображаемых сообщениях об ошибке будет указано, квота какого ресурса превышена. Например, далее показано сообщение о превышении квоты подключений.

Microsoft.ApplicationServer.Caching.DataCacheException: ErrorCode<ERRCA0017>:SubStatus<ES0009>:There is a temporary failure. Please retry later. (The request failed, because you exceeded quota limits for this hour. If you experience this often, upgrade your subscription to a higher one). Additional Information : Throttling due to resource : Connections.

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

通过