Поделиться через

Тестирование производительности с помощью Управляемого Redis в Azure (предварительная версия)

  • Статья

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

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

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

  1. Установите memtier на клиентских виртуальных машинах( виртуальных машинах), которые можно использовать для тестирования. Следуйте инструкциям по установке образа открытый код следуйте инструкциям в документации по Memtier.

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

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

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

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

  6. memtier_benchmark по умолчанию использует порт 6379. -p 10000 Используйте параметр для переопределения этого параметра, так как AMR использует порт 10000.

  7. Для всех экземпляров Управляемого Redis Azure с помощью политики кластера OSS необходимо добавить --cluster-mode параметр в команду memtier. Экземпляры AMR, использующие политику кластера Enterprise, можно рассматривать как некластеризованные кэши и не нуждаются в этом параметре.

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

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

  • Если вы не получаете необходимую производительность, попробуйте увеличить масштаб до более расширенного уровня. Уровень Balanced обычно имеет в два раза больше виртуальных ЦП, чем уровень "Оптимизированная для памяти", а уровень "Оптимизированная для вычислений" обычно имеет в два раза больше виртуальных ЦП, чем уровень Balanced. Так как Управляемый Redis Azure основан на Redis Enterprise, а не в сообществе Redis, основной процесс Redis может использовать несколько виртуальных ЦП. В результате экземпляры с большим объемом виртуальных ЦП имеют значительно более высокую производительность пропускной способности.

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

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

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

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

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

  • Конфигурация конвейера оказывает значительное влияние на тестирование производительности. Если задать значение параметра конвейера, вы увидите больше пропускной способности, но ухудшите задержку. Дополнительные сведения см. в разделе "Конвейер".

примеры memtier_benchmark

Примечание.

В этом примере показано тестирование для экземпляра X3, оптимизированного для вычислений, с помощью политики кластера OSS и TLS.

Предварительная настройка: подготовка экземпляра кэша с данными, необходимыми для тестирования. Загрузка экземпляра с данными гарантирует, что результаты более точно отражают реальные условия. Параметр {number-of-keys} должен определяться размером экземпляра AMR и размером каждого ключа. Хорошим правилом является заполнение экземпляра примерно 75 % полной, учет буферов. Эту формулу можно использовать: numberOfKeysToSet = (<TotalCacheSizeInBytes> * 0.75) / (1024 + 300) Например, если вы выполняете тест на экземпляре X3, оптимизированном для вычислений, с использованием 1024-байтовых размеров ключей, как показано ранее, это означает {number-of-keys} = (3 * 1000000000 * 0.75) / (1024 + 300). Результат равен примерно 1 699 396 ключам.

memtier_benchmark -h {your-cache-name}.{region}.redis.azure.net -p 10000 -a {your-access-key} --hide-histogram --pipeline=10 -clients=50 -threads=6 --key-maximum=1699396 -n allkeys --key-pattern=P:P --ratio=1:0 -data-size=1024 --tls --cluster-mode

Примечание.

В этом примере используются --tls--tls-skip-verifyфлаги , а также --cluster-mode флаги. Вам не нужно использовать Управляемый Redis Azure в режиме, отличном от TLS, или если вы используете политику кластера Enterprise соответственно.

Чтобы проверить пропускную способность: эта команда тестирует конвейерные запросы GET с полезными данными 1k. Эта команда позволяет проверить, сколько пропускной способности чтения ожидается от экземпляра кэша. В этом примере предполагается, что вы используете TLS и политику кластера OSS. Параметр --key-pattern=R:R гарантирует случайный доступ к ключам, повышая реалистичность теста. Этот тест выполняется в течение пяти минут.

memtier_benchmark -h {your-cache-name}.{region}.redis.azure.net -p 10000 -a {your-access-key} --hide-histogram --pipeline=10 -clients=50 -threads=6 -d 1024 --key-maximum=1699396 --key-pattern=R:R --ratio=0:1 --distinct-client-seed --test-time=300 --json-out-file=test_results.json --tls --tls-skip-verify --cluster-mode

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

В следующих таблицах показаны значения максимальной пропускной способности, которые наблюдались при тестировании различных размеров экземпляров Управляемого Redis Azure. Мы использовались memtier_benchmark из виртуальной машины IaaS Azure в конечной точке Управляемого Redis Azure, используя команды memtier, показанные в разделе memtier_benchmark примеров . Номера пропускной способности предназначены только для команд GET. Как правило, команды SET имеют меньшую пропускную способность. Производительность в реальном мире зависит от конфигурации и команд Redis. Эти числа предоставляются как точка ссылки, а не гарантия.

Внимание

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

Внимание

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

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

Тесты для обеих политик кластера показаны в следующих таблицах. Для таблицы политик кластера OSS предоставляются две конфигурации тестирования:

  • 300 подключений (50 клиентов и 6 потоков)
  • 2500 подключений (50 клиентов и 50 потоков)

Второе тестирование обеспечивается, так как 300 подключений недостаточно для полного демонстрации производительности экземпляров большего кэша.

Ниже приведена пропускная способность в операциях GET в секунду на 1 кб полезных данных для экземпляров AMR, а также количество клиентских подключений, используемых для тестирования. Все числа вычислялись для экземпляров AMR с SSL-подключениями, а пропускная способность сети записывается в Мбит/с.

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

Размер в ГБ VCPU/Network BW/Memory Optimized vCPU/Network BW/Balanced VCPU/Network BW/Compute Optimized
1 - 2/5,000/103,500 -
3 - 2/2,000/104,500 4/10,000/221,100
6 - 2/2,000/106,500 4/10,000/210,850
12 2/2,000/106,000 4/4,000/223,900 8/12,500/499,900
24 4/4,000/227,800 8/8,000/495,300 16/12,500/485,920
60 8/8,000/496,000 16/10,000/476,500 32/16,000/454,200
120 16/10,000/476,200 32/16,000/462,200 64/28,000/463,800

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

Размер в ГБ VCPU/Network BW/Memory Optimized vCPU/Network BW/Balanced VCPU/Network BW/Compute Optimized
1 - 2/5,000/56,900 -
3 - 2/2,000/56,900 4/10,000/118,900
6 - 2/2,000/59,200 4/10,000/111,950
12 2/2,000/55,800 4/4,000/118,500 8/12,500/206,500
24 4/4,000/122,000 8/8,000/205,500 16/12,500/294,700
60 8/8,000/208,100 16/10,000/293,400 32/16,000/441,400
120 16/10,000/285,600 32/16,000/451,700 64/28,000/516,200