Тестирование производительности с помощью Управляемого 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

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