Тестирование производительности
Тестирование производительности экземпляра Redis может быть сложной задачей. Производительность экземпляра Redis может отличаться в зависимости от параметров, таких как количество клиентов, размер значений данных и использование конвейера. Существует также компромисс между оптимизацией пропускной способности или задержкой.
К счастью, существует несколько инструментов, чтобы упростить тестирование Redis. Два из самых популярных инструментов — redis-benchmark и memtier-benchmark. В этой статье рассматривается redis-benchmark.
Использование служебной программы redis-benchmark
Установите открытый код сервер Redis на виртуальную машину клиента, который можно использовать для тестирования. Программа redis-benchmark встроена в распределение Redis открытый код Redis. Следуйте инструкциям по установке образа открытый код Redis.
Виртуальная машина клиента, используемая для тестирования, должна находиться в том же регионе, что и экземпляр Кэш Azure для Redis.
Убедитесь, что используемая клиентская виртуальная машина имеет по крайней мере столько вычислительных ресурсов и пропускной способности , сколько проверяется экземпляр кэша.
Настройте параметры сетевой изоляции и брандмауэра, чтобы убедиться, что клиентская виртуальная машина сможет получить доступ к Кэш Azure для Redis экземпляру.
Если вы используете TLS/SSL в экземпляре кэша, необходимо добавить
--tlsпараметр в команду redis-benchmark или использовать прокси-сервер, например stunnel.Redis-benchmarkпо умолчанию использует порт 6379.-pИспользуйте параметр для переопределения этого параметра. Необходимо использовать-p, если вы используете ПРОТОКОЛ SSL/TLS (порт 6380) или используете корпоративный уровень (порт 10000).Если вы используете экземпляр Кэш Azure для Redis, использующий кластеризация, необходимо добавить
--clusterпараметр вredis-benchmarkкоманду. Кэши уровня предприятия с помощью политики корпоративного кластеризация можно рассматривать как некластеризованные кэши и не нуждаться в этом параметре.Запустите
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 использовать больше виртуальных ЦП путем сегментирования данных. Пропускная способность должна увеличиваться примерно линейно при добавлении сегментов в этом случае.
Примеры 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
Внимание
Эти значения не гарантированы, и для этих чисел нет соглашение об уровне обслуживания. Настоятельно рекомендуется выполнить собственное тестирование производительности, чтобы определить правильный размер кэша для приложения. Эти числа могут изменяться при периодическом обновлении результатов.
Внимание
Корпорация Майкрософт периодически обновляет базовую виртуальную машину, используемую в экземплярах кэша. Это может изменить характеристики производительности из кэша в кэш и из региона в регион. Примеры значений тестирования на этой странице отражают оборудование кэша старшего поколения в одном регионе. Вы можете увидеть лучшие или разные результаты на практике.
Уровень служб "Стандартный"
| Экземпляр | Размер | Число виртуальных ЦП | Ожидаемая пропускная способность сети (Мбит/с) | Запросы GET в секунду без SSL (размер значения 1 кб) | Запросы GET в секунду с SSL (размер значения 1 кб) |
|---|---|---|---|---|---|
| C0 | 250 МБ | Совмещаемая блокировка | 100 | 15 000 | 7500 |
| C1 | 1 ГБ | 1 | 500 | 38 000 | 20 720 |
| C2 | 2.5 ГБ | 2 | 500 | 41 000 | 37 000 |
| C3 | 6 ГБ | 4 | 1000 | 100,000 | 90 000 |
| C4 | 13 ГБ | 2 | 500 | 60 000 | 55 000 |
| C5 | 26 ГБ | 4 | 1,000 | 102 000 | 93 000 |
| C6 | 53 ГБ | 8 | 2 000 | 126 000 | 120 000 |
Уровень служб "Премиум"
| Экземпляр | Размер | Число виртуальных ЦП | Ожидаемая пропускная способность сети (Мбит/с) | Запросы GET в секунду без SSL (размер значения 1 кб) | Запросы GET в секунду с SSL (размер значения 1 кб) |
|---|---|---|---|---|---|
| P1 | 6 ГБ | 2 | 1500 | 180 000 | 172 000 |
| P2 | 13 ГБ | 4 | 3,000 | 350 000 | 341 000 |
| P3 | 26 ГБ | 4 | 3,000 | 350 000 | 341 000 |
| P4 | 53 ГБ | 8 | 6000 | 400 000 | 373 000 |
| P5 | 120 ГБ | 32 | 6000 | 400 000 | 373 000 |
Внимание
Экземпляры P5 в регионах "Восточный Китай" и "Северный Китай" используют 20 ядер, а не 32.
Уровни 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
Примечание.
Эта конфигурация почти идентична той, которая используется для тестирования уровней "Базовый", "Стандартный" и "Премиум". Однако предыдущая конфигурация не полностью использует более высокую производительность вычислений уровней Enterprise. В эту конфигурацию добавлены дополнительные запросы и потоки, чтобы продемонстрировать полную производительность.
Политика корпоративного кластера
| Экземпляр | Размер | Число виртуальных ЦП | Ожидаемая пропускная способность сети (Мбит/с) | Запросы GET в секунду без SSL (размер значения 1 кб) | Запросы GET в секунду с SSL (размер значения 1 кб) |
|---|---|---|---|---|---|
| E10 | 12 ГБ | 4 | 4000 | 300 000 | 207,000 |
| E20 | 25 ГБ | 4 | 4000 | 680,000 | 480,000 |
| E50 | 50 ГБ | 8 | 8000 | 1 200 000 | 900 000 |
| E100 | 100 ГБ | 16 | 10,000 | 1,700,000 | 1,650,000 |
| F300 | 384 ГБ | 8 | 3200 | 500,000 | 390,000 |
| F700 | 715 ГБ | 16 | 6400 | 500,000 | 370,000 |
| F1500 | 1455 ГБ | 32 | 12 800 | 530,000 | 390,000 |
Политика кластера OSS
| Экземпляр | Размер | Число виртуальных ЦП | Ожидаемая пропускная способность сети (Мбит/с) | Запросы GET в секунду без SSL (размер значения 1 кб) | Запросы GET в секунду с SSL (размер значения 1 кб) |
|---|---|---|---|---|---|
| E10 | 12 ГБ | 4 | 4000 | 1 400 000 | 1 000 000 |
| E20 | 25 ГБ | 4 | 4000 | 1 200 000 | 900 000 |
| E50 | 50 ГБ | 8 | 8000 | 2,300,000 | 1,700,000 |
| E100 | 100 ГБ | 16 | 10,000 | 3 000 000 | 2 500 000 |
| F300 | 384 ГБ | 8 | 3200 | 1,500,000 | 1 200 000 |
| F700 | 715 ГБ | 16 | 6400 | 1 600 000 | 1 200 000 |
| F1500 | 1455 ГБ | 32 | 12 800 | 1 600 000 | 1,110,000 |
Корпоративные и корпоративные уровни флэш-памяти — горизонтальное масштабирование
Помимо масштабирования путем перемещения в более крупный размер кэша, можно повысить производительность, масштабируясь. На уровнях Enterprise масштабирование вызывается увеличение емкости экземпляра кэша. Экземпляр кэша по умолчанию имеет емкость двухзначного первичного и реплика узла. Экземпляр кэша Enterprise с емкостью 4 указывает, что экземпляр был масштабирован на два. Масштабирование обеспечивает доступ к большему объему памяти и виртуальным ЦП. Сведения о том, сколько виртуальных ЦП используется основным процессом Redis для каждого размера кэша и емкости, можно найти на странице рекомендаций по уровням Enterprise. Масштабирование наиболее эффективно при использовании политики кластера OSS.
В следующих таблицах показаны запросы GET в секунду в разных емкостях с использованием SSL и размера значения 1 кб.
Горизонтальное масштабирование — политика корпоративного кластера
| Экземпляр | Емкость 2 | Емкость 4 | Емкость 6 |
|---|---|---|---|
| E10 | 200 000 | 830,000 | 930,000 |
| E20 | 480,000 | 710,000 | 950 000 |
| E50 | 900 000 | 1,110,000 | 1 200 000 |
| E100 | 1 600 000 | 1,120,000 | 1 200 000 |
| Экземпляр | Емкость 3 | Емкость 9 |
|---|---|---|
| F300 | 390,000 | 640,000 |
| F700 | 370,000 | 610,000 |
| F1500 | 390,000 | 670,000 |
Горизонтальное масштабирование — политика кластера OSS
| Экземпляр | Емкость 2 | Емкость 4 | Емкость 6 |
|---|---|---|---|
| E10 | 1 000 000 | 1,900,000 | 2 500 000 |
| E20 | 900 000 | 1,700,000 | 2,300,000 |
| E50 | 1,700,000 | 3 000 000 | 3,900,000 |
| E100 | 2 500 000 | 4,400,000 | 4,900,000 |
| Экземпляр | Емкость 3 | Емкость 9 |
|---|---|---|
| F300 | 1 200 000 | 2,600,000 |
| F700 | 1 200 000 | 2,600,000 |
| F1500 | 1,100,000 | 2,800,000 |