Тестирование производительности

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

К счастью, существует несколько инструментов, чтобы упростить тестирование Redis. Два из самых популярных инструментов — redis-benchmark и memtier-benchmark. В этой статье рассматривается redis-benchmark.

Использование служебной программы redis-benchmark

1. Установите открытый код сервер Redis на клиентские виртуальные машины( виртуальные машины), которые можно использовать для тестирования. Программа redis-benchmark встроена в распределение Redis открытый код Redis. Следуйте инструкциям по установке образа открытый код Redis.

2. Виртуальная машина клиента, используемая для тестирования, должна находиться в том же регионе, что и экземпляр Кэш Azure для Redis.

3. Убедитесь, что используемая клиентская виртуальная машина имеет по крайней мере столько вычислительных ресурсов и пропускной способности , сколько проверяется экземпляр кэша.

4. Настройте параметры сетевой изоляции и брандмауэра, чтобы убедиться, что клиентская виртуальная машина сможет получить доступ к Кэш Azure для Redis экземпляру.

5. Если вы используете TLS/SSL в экземпляре кэша, необходимо добавить --tls параметр в команду redis-benchmark или использовать прокси-сервер, например stunnel.

6. Redis-benchmark по умолчанию использует порт 6379. -p Используйте параметр для переопределения этого параметра. Необходимо использовать -p, если вы используете ПРОТОКОЛ SSL/TLS (порт 6380) или используете корпоративный уровень (порт 10000).

7. Если вы используете Кэш Azure для Redis экземпляр, использующий кластеризацию, необходимо добавить --cluster параметр в redis-benchmark команду. Кэши уровня предприятия, использующие политику кластеризации Enterprise, можно рассматривать как некластеризованные кэши и не нуждаться в этом параметре.

8. Запустите redis-benchmark интерфейс командной строки или оболочку виртуальной машины. Инструкции по настройке и запуску средства см. в документации redis-benchmark и примерах redis-benchmark.

Рекомендации по тестированию

• Важно не только проверить производительность кэша в условиях устойчивого состояния. Также проведите тестирование в условиях обработки отказа и измерьте нагрузку на ЦП/сервер в кэше за это время. Вы можете запустить отработку отказа, перезагрузив основной узел. Тестирование в условиях обработки отказа позволяет вам увидеть пропускную способность и задержку вашего приложения в условиях аварийного переключения. Обработка отказа может произойти во время обновлений или во время незапланированного события. В идеале вы не хотите видеть пик загрузки ЦП или сервера до более чем 80 % даже во время отработки отказа, так как это может повлиять на производительность.

• Рассмотрите возможность использования экземпляров уровня Enterprise и Premium Кэш Azure для Redis. Эти размеры кэша имеют лучшую задержку сети и пропускную способность, так как они работают на лучшем оборудовании.

• Уровень Enterprise обычно имеет лучшую производительность, так как Redis Enterprise позволяет основному процессу Redis использовать несколько виртуальных ЦП. Уровни на основе открытый код Redis, таких как Standard и Premium, могут использовать только один виртуальный ЦП для процесса Redis на сегмент.

• Тестирование уровня Enterprise Flash может быть сложным, так как некоторые ключи хранятся в DRAM, а некоторые хранятся на флэш-диске NVMe. Ключи на тесте DRAM почти так быстро, как экземпляр уровня Enterprise, но ключи на диске флэш-памяти NVMe медленнее. Так как уровень Enterprise Flash интеллектуально помещает наиболее используемые ключи в DRAM, убедитесь, что конфигурация теста соответствует фактическому использованию, которое вы ожидаете. Рекомендуется использовать -r параметр для случайной выборки доступа к ключам.

• Использование TLS/SSL снижает производительность пропускной способности, которую можно четко увидеть в примерах тестовых данных в следующих таблицах.

• Несмотря на то, что сервер Redis является однопоточным, увеличение масштаба, как правило, повышает производительность пропускной способности. Системные процессы могут использовать дополнительные виртуальные ЦП вместо совместного использования виртуального ЦП, используемого процессом Redis. Масштабирование особенно полезно на уровнях Enterprise и Enterprise Flash, так как Redis Enterprise не ограничивается одним потоком. Дополнительные сведения см. в рекомендациях по уровню Enterprise.

• На уровне "Премиум" рекомендуется масштабировать кластеризацию перед увеличением масштаба. Кластеризация позволяет серверу Redis использовать больше виртуальных ЦП путем сегментирования данных. Пропускная способность должна увеличиваться примерно линейно при добавлении сегментов в этом случае.

• В кэшах C0 и C1 уровня "Стандартный", в то время как внутренняя проверка Defender выполняется на виртуальных машинах, может возникнуть короткий пик нагрузки на сервер, не вызванный увеличением запросов кэша. Вы видите более высокую задержку для запросов, пока внутренние проверки Защитника выполняются на этих уровнях несколько раз в день. Кэши на уровнях C0 и C1 имеют только один ядро для многозадачных операций, разделяя работу обслуживания внутренних запросов защитника и запросов Redis. Эффект можно уменьшить, масштабируя до более высокого уровня, используя несколько ядер ЦП, например C2.

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

Примеры Redis-тестов

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

redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t SET -n 10 -d 1024

Чтобы проверить задержку: проверьте запросы GET, используя полезную нагрузку размером 1 КБ:

redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t GET -d 1024 -P 50 -c 4

Для проверки пропускной способности: конвейерные запросы GET с полезной нагрузкой 1 КБ:

redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t  GET -n 1000000 -d 1024 -P 50  -c 50

Чтобы проверить пропускную способность кэша уровня "Базовый", "Стандартный" или "Премиум" с помощью TLS: конвейерные запросы GET с полезными данными 1k:

redis-benchmark -h yourcache.redis.cache.windows.net -p 6380 -a yourAccesskey -t  GET -n 1000000 -d 1024 -P 50 -c 50 --tls

Чтобы проверить пропускную способность кэша Enterprise или Enterprise Flash без TLS с помощью режима кластера OSS: конвейерные запросы GET с полезными данными 1k:

redis-benchmark -h yourcache.region.redisenterprise.cache.azure.net -p 10000 -a yourAccesskey -t  GET -n 1000000 -d 1024 -P 50 -c 50 --cluster

Примеры данных теста производительности

В следующих таблицах показаны максимальные значения пропускной способности, которые наблюдались при тестировании различных размеров кэшей Standard, Premium, Enterprise и Enterprise Flash. Мы использовали из redis-benchmark виртуальной машины Azure IaaS в конечной точке Кэш Azure для Redis. Номера пропускной способности предназначены только для команд GET. Как правило, команды SET имеют меньшую пропускную способность. Эти числа оптимизированы для пропускной способности. Реальная пропускная способность при допустимых условиях задержки может быть ниже.

Следующая конфигурация использовалась для тестирования пропускной способности для уровней "Базовый", "Стандартный" и "Премиум".

redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t  GET -n 1000000 -d 1024 -P 50  -c 50

Уровень служб "Стандартный"

Уровень служб "Премиум"

Уровни Enterprise и Enterprise Flash

Уровни Enterprise и Enterprise Flash предлагают выбор политики кластера: Enterprise и OSS. Корпоративная политика кластера — это более простая конфигурация, которая не требует от клиента поддержки кластеризации. С другой стороны, политика кластера OSS использует протокол кластера Redis для поддержки более высокой пропускной способности. В большинстве случаев рекомендуется использовать политику кластера OSS. Дополнительные сведения см. в разделе "Кластеризация на предприятии". Тесты для обеих политик кластера показаны в следующих таблицах.

Следующая конфигурация использовалась для тестирования пропускной способности для уровней флэш-памяти Enterprise и Enterprise:

redis-benchmark -h yourcache.region.redisenterprise.cache.azure.net -p 10000 -a yourAccesskey -t GET -n 10000000 -d 1024 -P 50 -c 50 --threads 32

Политика корпоративного кластера

Политика кластера OSS

Корпоративные и корпоративные уровни флэш-памяти — горизонтальное масштабирование

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

В следующих таблицах показаны GET запросы в секунду в разных емкостях с использованием SSL и размера значения 1 кб.

Горизонтальное масштабирование — политика корпоративного кластера

Горизонтальное масштабирование — политика кластера OSS

Следующие шаги

• Разработка
• Кэш Redis для Azure: разработка — вопросы и ответы
• Отработка отказа и исправление в службе "Кэш Azure для Redis"