Анализ производительности сервера Redis на Ubuntu 18.04

Ubuntu | Amber | Комментировать запись

Сравнительный анализ (benchmarking) является важной составляющей анализа общей производительности серверов баз данных. Это помогает выявить узкие места, а также открывает возможности для улучшения системы.

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

В этом мануале мы покажем, как проанализировать производительность сервера Redis на Ubuntu 18.04, используя несколько различных инструментов и методов.

Требования

• Сервер Ubuntu 18.04, настроенный по этому мануалу.
• Установка Redis. За помощью можно обратиться к руководству Установка и защита Redis в в Ubuntu 18.04.

Примечание: Данный мануал выполнен на выделенном сервере Redis (4 Гб).

1: Инструмент redis-benchmark

Redis поставляется с инструментом тестирования redis-benchmark. Эта программа может симулировать произвольное число клиентов, одновременно подключающихся и выполняющих действия на сервере, и измерить, сколько времени требуется для выполнения запросов. Полученные данные дадут вам представление о среднем количестве запросов, которое сервер Redis может обрабатывать в секунду.

В следующем списке приведены некоторые общие параметры для redis-benchmark:

• -h: хост Redis (по умолчанию 127.0.0.1).
• -p: порт Redis (по умолчанию 6379).
• -a: эта опция позволяет указать пароль, если серверу нужна аутентификация.
• -c: задает количество клиентов (параллельных соединений), которое нужно симулировать. По умолчанию это 50 клиентов.
• -n: количество симулируемых запросов (по умолчанию 100000).
• -d: размер данных в байтах для значений SET и GET (по умолчанию 3).
• -t: запускает только поднабор тестов. К примеру, можно использовать -t get,set и измерить только производительность команд GET и SET.
• -P: использует конвейерную обработку для улучшения производительности.
• -q: тихий режим, показывает только среднее количество запросов в секунду.

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

redis-benchmark -q

Вы получите примерно такой результат:

PING_INLINE: 85178.88 requests per second
PING_BULK: 83056.48 requests per second
SET: 72202.16 requests per second
GET: 94607.38 requests per second
INCR: 84961.77 requests per second
LPUSH: 78988.94 requests per second
RPUSH: 88652.48 requests per second
LPOP: 87950.75 requests per second
RPOP: 80971.66 requests per second
SADD: 80192.46 requests per second
HSET: 84317.03 requests per second
SPOP: 78125.00 requests per second
LPUSH (needed to benchmark LRANGE): 84175.09 requests per second
LRANGE_100 (first 100 elements): 52383.45 requests per second
LRANGE_300 (first 300 elements): 21547.08 requests per second
LRANGE_500 (first 450 elements): 14471.78 requests per second
LRANGE_600 (first 600 elements): 9383.50 requests per second
MSET (10 keys): 71225.07 requests per second

Вы также можете ограничиться в тестах только подмножеством команд по вашему выбору, используя параметр -t. Следующая команда покажет средние значения только для команд GET и SET:

redis-benchmark -t set,get -q
SET: 76687.12 requests per second
GET: 82576.38 requests per second

По умолчанию команда симулирует 50 параллельных соединений и 100000 запросов к серверу Redis. Если вы хотите увеличить количество параллельных соединений и симулировать пик в нагрузке, вы можете использовать опцию -c:

redis-benchmark -t set,get -q -c 1000

Поскольку при этом команда симулирует 1000 одновременных подключений вместо 50, вам следует ожидать снижения производительности:

SET: 69444.45 requests per second
GET: 70821.53 requests per second

Чтобы получить в выводе подробную информацию, удалите опцию –q. Следующая команда использует 100 параллельных соединений и запускает 1000000 SET-запросов на сервере.

redis-benchmark -t set -c 100 -n 1000000

Вы получите примерно следующее:

====== SET ======
1000000 requests completed in 11.29 seconds
100 parallel clients
3 bytes payload
keep alive: 1
95.22% <= 1 milliseconds
98.97% <= 2 milliseconds
99.86% <= 3 milliseconds
99.95% <= 4 milliseconds
99.99% <= 5 milliseconds
99.99% <= 6 milliseconds
100.00% <= 7 milliseconds
100.00% <= 8 milliseconds
100.00% <= 8 milliseconds
88605.35 requests per second

По умолчанию для значения ключа используется 3 байта. Вы можете изменить это значение с помощью опции -d. Следующая команда анализирует команды GET и SET с ключами размером в 1 МБ:

redis-benchmark -t set,get -d 1000000 -n 1000 -q

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

SET: 1642.04 requests per second
GET: 822.37 requests per second

Важно понимать вот что: хотя эти числа полезны в качестве быстрого способа оценки производительности экземпляра Redis, они не представляют максимальную пропускную способность, которую может выдержать экземпляр Redis. Используя конвейерную обработку, приложения могут отправлять несколько команд одновременно, чтобы увеличить количество запросов в секунду, которые может обрабатывать сервер. Команда redis-benchmark использует опцию -P для имитации реальных приложений, использующих эту функцию Redis.

Чтобы сравнить разницу, сначала запустите команду redis-benchmark со значениями по умолчанию и без конвейеризации для тестирования GET и SET:

redis-benchmark -t get,set -q
SET: 86281.27 requests per second
GET: 89847.26 requests per second

Следующая команда выполнит те же тесты, но конвейеризирует 8 команд:

redis-benchmark -t get,set -q -P 8
SET: 653594.81 requests per second
GET: 793650.75 requests per second

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

2: Проверка задержки с помощью redis-cli

Если вы просто хотите измерить среднее время, которое требуется для получения ответа на запрос, проверьте среднюю задержку сервера с помощью клиента Redis. В контексте Redis задержка определяет, сколько времени уходит у команды ping на получение ответа от сервера.

Следующая команда покажет статистику задержки в реальном времени для вашего сервера Redis:

redis-cli --latency

Вы получите вывод, который покажет увеличивающееся количество выборок и среднюю задержку:

min: 0, max: 1, avg: 0.18 (970 samples)

Эта команда будет работать бесконечно. Вы можете остановить ее с помощью CTRL + C.

Чтобы отследить задержку в течение определенного периода времени, вы можете использовать такую опцию:

redis-cli --latency-history

Это позволит отследить среднее значение задержки в течение времени с настраиваемым интервалом (по умолчанию это 15 секунд). Вы получите примерно такой вывод:

min: 0, max: 1, avg: 0.18 (1449 samples) -- 15.01 seconds range
min: 0, max: 1, avg: 0.16 (1449 samples) -- 15.00 seconds range
min: 0, max: 1, avg: 0.17 (1449 samples) -- 15.00 seconds range
min: 0, max: 1, avg: 0.17 (1444 samples) -- 15.01 seconds range
min: 0, max: 1, avg: 0.17 (1446 samples) -- 15.01 seconds range
min: 0, max: 1, avg: 0.17 (1449 samples) -- 15.00 seconds range
min: 0, max: 1, avg: 0.16 (1444 samples) -- 15.00 seconds range
min: 0, max: 1, avg: 0.17 (1445 samples) -- 15.01 seconds range
min: 0, max: 1, avg: 0.16 (1445 samples) -- 15.01 seconds range
…

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

Если вы хотите измерить только системную задержку, вы можете использовать опцию –intrinsic-latency. Внутренняя задержка присуща среде и зависит от таких факторов, как оборудование, ядро, соседние ноды сервера и другие факторы, которые не подчиняются Redis.

Внутреннюю задержку можно воспринимать как основу общей производительности Redis. Следующая команда проверит внутреннюю задержку системы с помощью теста в течение 30 секунд:

redis-cli --intrinsic-latency 30

Вы должны получить похожий вывод:

…
498723744 total runs (avg latency: 0.0602 microseconds / 60.15 nanoseconds per run).
Worst run took 22975x longer than the average latency.

Сравнение результатов тестов задержки поможет вам выявить аппаратные или системные узкие места, которые могут повлиять на производительность Redis. Учитывая, что общее время задержки для запроса к нашему серверу составляет в среднем 0,18 микросекунды, внутренняя задержка 0,06 микросекунды означает, что одна треть общего времени запроса тратится на процессы, которые не контролируются Redis.

3: Инструмент Memtier

Memtier – это высокопроизводительный инструмент для тестирования Redis и Memcached, созданный Redis Labs. Несмотря на то, что Memtier очень похож на redis-benchmark в некоторых аспектах, он более гибкий. Он предоставляет несколько параметров конфигурации, с помощью которых можно тоньше настроить эмуляцию нагрузки сервера Redis (в дополнение к поддержке кластера).

Чтобы установить Memtier на ваш сервер, необходимо скомпилировать его из исходного кода. Сначала установите зависимости, необходимые для компиляции кода:

sudo apt-get install build-essential autoconf automake libpcre3-dev libevent-dev pkg-config zlib1g-dev

Затем перейдите в домашний каталог и клонируйте проект memtier_benchmark из его репозитория Github:

cd
git clone https://github.com/RedisLabs/memtier_benchmark.git

Перейдите в каталог проекта и выполните команду autoreconf, чтобы сгенерировать сценарии конфигурации приложения:

cd memtier_benchmark
autoreconf -ivf

Запустите скрипт configure для генерации артефактов приложения, необходимых для компиляции:

./configure

Теперь запустите make, чтобы скомпилировать приложение:

make

Как только сборка будет завершена, вы можете протестировать исполняемый файл с помощью этой команды:

./memtier_benchmark --version

Вы получите следующий вывод:

memtier_benchmark 1.2.17
Copyright (C) 2011-2017 Redis Labs Ltd.
This is free software.  You may redistribute copies of it under the terms of
the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
There is NO WARRANTY, to the extent permitted by law.

Следующий список содержит наиболее распространенные параметры команды memtier_benchmark:

• -s: хост (по умолчанию это localhost).
• -p: порт сервера (по умолчанию 6379).
• -a: аутентификация с помощью указанного пароля.
• -n: количество запросов на одного клиента (по умолчанию 10000).
• -c: количество клиентов (по умолчанию 50).
• -t: количество потоков (по умолчанию 4).
• –pipeline: включает конвейерную обработку
• –ratio: соотношение между командами SET и GET, по умолчанию 1:10.
• –hide-histogram: Скрывает подробную информацию о выводе.

Большинство из этих параметров очень похожи на параметры, представленные в redis-benchmark, но Memtier тестирует производительность по-другому. Чтобы лучше имитировать обычную реальную среду, стандартные тесты memtier_benchmark проверяют только запросы GET и SET в соотношении 1:10 (10 операций GET для каждой операции SET). Эта схема является более показательной для обычного веб-приложения на Redis. Вы можете настроить значение коэффициента с помощью опции –ratio.

Следующая команда запускает memtier_benchmark с параметрами по умолчанию, предоставляя в выводе только информацию высокого уровня.

./memtier_benchmark --hide-histogram

Примечание: Если ваш сервер Redis требует аутентификации, вы должны добавить в команду параметр -a вместе с паролем Redis:

./memtier_benchmark --hide-histogram -a your_redis_password

Вы увидите такой вывод:

…
4         Threads
50        Connections per thread
10000     Requests per client
ALL STATS
=========================================================================
Type         Ops/sec     Hits/sec   Misses/sec      Latency       KB/sec
-------------------------------------------------------------------------
Sets         8258.50          ---          ---      2.19800       636.05
Gets        82494.28     41483.10     41011.18      2.19800      4590.88
Waits           0.00          ---          ---      0.00000          ---
Totals      90752.78     41483.10     41011.18      2.19800      5226.93

Согласно этому тесту memtier_benchmark, сервер Redis может выполнять около 90 тысяч операций в секунду в соотношении 1:10 SET/GET.

Важно отметить, что у каждого инструмента есть свой алгоритм тестирования производительности и представления данных. По этой причине они выдают разные результаты на одном сервере даже при использовании аналогичных настроек – это нормально.

Заключение

В этом мануале вы узнали, как выполнять тесты производительности на сервере Redis, используя два различных инструмента: встроенный инструмент Redis-Benchmark и инструмент memtier_benchmark, разработанный Redis Labs. Вы также увидели, как проверить задержку сервера с помощью redis-cli. Основываясь на данных, полученных в ходе этих тестов, вы лучше поймете, чего ожидать от вашего сервера Redis и каковы узкие места вашей текущей настройки.