Бенчмарк Redis под Twemproxy с редис-тестом
Я пытаюсь протестировать очень простую установку с Redis и Twemproxy, но не могу найти способ сделать это быстрее.
У меня есть 2 сервера Redis, которые я запускаю с минимальной конфигурацией:
./redis-server --port 6370
./redis-server --port 6371
Оба скомпилированы из исходного кода и работают под 1 машиной со всей соответствующей памятью и процессорами.
Если я запускаю тест Redis в одном из случаев, я получаю следующее:
./redis-benchmark --csv -q -p 6371 -t set,get,incr,lpush,lpop,sadd,spop -r 100000000
"SET","161290.33"
"GET","176366.86"
"INCR","170940.17"
"LPUSH","178571.42"
"LPOP","168350.17"
"SADD","176991.16"
"SPOP","168918.92"
Теперь я хотел бы использовать Twemproxy перед двумя экземплярами, чтобы распределить запросы и получить более высокую пропускную способность (по крайней мере, это то, что я ожидал!).
Я использовал следующую конфигурацию для Twemproxy:
my_cluster:
listen: 127.0.0.1:6379
hash: fnv1a_64
distribution: ketama
auto_eject_hosts: false
redis: true
servers:
- 127.0.0.1:6371:1 server1
- 127.0.0.1:6372:1 server2
И я запускаю Щелкунчик как:
./nutcracker -c twemproxy_redis.yml -i 5
Результаты очень разочаровывают:
./redis-benchmark -r 1000000 --csv -q -p 6379 -t set,get,incr,lpush,lpop,sadd,spop-q -p 6379
"SET","112485.94"
"GET","113895.21"
"INCR","110987.79"
"LPUSH","145560.41"
"LPOP","149700.61"
"SADD","122100.12"
Я попытался понять, что происходит, получив статистику Twemproxy:
telnet 127.0.0.1 22222
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
{
"service": "nutcracker",
"source": "localhost.localdomain",
"version": "0.4.1",
"uptime": 10,
"timestamp": 1452545028,
"total_connections": 303,
"curr_connections": 3,
"my_cluster": {
"client_eof": 300,
"client_err": 0,
"client_connections": 0,
"server_ejects": 0,
"forward_error": 0,
"fragments": 0,
"server1": {
"server_eof": 0,
"server_err": 0,
"server_timedout": 0,
"server_connections": 1,
"server_ejected_at": 0,
"requests": 246791,
"request_bytes": 11169484,
"responses": 246791,
"response_bytes": 1104215,
"in_queue": 0,
"in_queue_bytes": 0,
"out_queue": 0,
"out_queue_bytes": 0
},
"server2": {
"server_eof": 0,
"server_err": 0,
"server_timedout": 0,
"server_connections": 1,
"server_ejected_at": 0,
"requests": 353209,
"request_bytes": 12430516,
"responses": 353209,
"response_bytes": 2422648,
"in_queue": 0,
"in_queue_bytes": 0,
"out_queue": 0,
"out_queue_bytes": 0
}
}
}
Connection closed by foreign host.
Есть ли другие тесты, которые работают правильно? Или же redis-benchmark
должен был работать?
Я забыл упомянуть, что я использую Redis: 3.0.6 и Twemproxy: 0.4.1
2 ответа
Это может показаться нелогичным, но размещение двух экземпляров redis с прокси-сервером перед ними, безусловно, снизит производительность!
В сценарии с одним экземпляром Redis-Benchmark подключается непосредственно к серверу Redis и, таким образом, имеет минимальную задержку на запрос.
Как только вы поместите два экземпляра и один twemproxy перед ними, подумайте, что происходит - вы подключаетесь к twemproxy, который анализирует запрос, выбирает правильный экземпляр и подключается к нему.
Итак, во-первых, у каждого запроса теперь есть два сетевых прыжка вместо одного. Добавленная задержка означает меньшую пропускную способность, конечно.
Кроме того, вы используете только один экземпляр twemproxy. Итак, давайте предположим, что twemproxy сам по себе работает более или менее как один экземпляр Redis, вы никогда не сможете превзойти один экземпляр с одним прокси.
Twemproxy облегчает масштабирование, а не масштабирование. Это позволяет вам наращивать кластер до размеров, которых никогда не сможет достичь один экземпляр. Но есть цена задержки, которую нужно заплатить, и если вы используете один прокси, это также цена за пропускную способность.
Прокси облагается небольшим налогом на каждый запрос. Измерьте пропускную способность, используя прокси с одним сервером. Наложите нагрузку до тех пор, пока пропускная способность не перестанет расти, а время отклика замедлится до сканирования. Добавьте другой сервер и обратите внимание, что время отклика восстановлено до нормального, а емкость просто удвоилась. Конечно, вы захотите добавить серверы задолго до начала сканирования.