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

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

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

Использование служебной программы 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 SSD диске медленнее. Так как уровень оптимизации для флэш-памяти интеллектуально помещает наиболее используемые ключи в DRAM, убедитесь, что конфигурация теста соответствует ожидаемому использованию.

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

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

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

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

Примеры "memtier_benchmark"

Предварительная настройка: подготовка экземпляра кэша с данными, необходимыми для тестирования. Загрузка экземпляра с данными гарантирует, что результаты более точно отражают реальные условия. Параметр {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

Чтобы проверить пропускную способность: эта команда тестирует конвейерные GET-запросы с нагрузкой в 1 килобайт. Эта команда позволяет проверить, сколько пропускной способности чтения ожидается от экземпляра кэша. В этом примере предполагается, что вы используете 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 с нагрузкой из всех команд чтения и полезной нагрузкой 1 КБ. Рабочая нагрузка одинакова по всем единицам складского учета (SKU), за исключением числа подключений (то есть разного количества потоков и клиентов в соответствии с требованиями memtier_benchmark). Количество подключений выбирается для SKU, чтобы оптимально использовать Управляемый экземпляр Redis в Azure. Мы использовали memtier_benchmark из виртуальной машины IaaS Azure по отношению к конечной точке Управляемого Redis Azure, используя команды memtier, показанные в разделе примеров memtier_benchmark. Номера пропускной способности предназначены только для команд GET. Как правило, команды SET имеют меньшую пропускную способность. Производительность в реальном мире зависит от конфигурации и команд Redis. Эти числа предоставляются как точка ссылки, а не гарантия.

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

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

Дальнейшие шаги

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