Comments 3
Я так понял, вы на каждый запрос к веб-серверу открываете новый коннект к тарантулу чтобы сделать один простой запрос? Я плохо знаком с nginx-расширениями, но нельзя ли держать постоянное подключение к тарантулу и через него слать запросы?
3500 rps это как-то очень и очень мало.
3500 rps это как-то очень и очень мало.
+1
1. Обратите внимание на фрагмент:
Метод set_keepalive() как раз и возращает соединение в пул NGINX. И оно может быть повторно использованно другим запросом.
2. Казалось бы да, 3500 RPS это не много, но не забываем что на тестовой машине было задействовано всего одно ядро. И один worker-процесс NGINX (которому ещё и TLS делать надо) делил CPU с Тарантулом.
Если выделить NGINX побольше ядер (например 30), и освободить как минимум одно ядро для Тарантула, то можно получить существенно более радостную картину:
if not tar:set_keepalive() then
ngx.log(ngx.WARN, "TNT connection not set as keep-alive.")
end
Метод set_keepalive() как раз и возращает соединение в пул NGINX. И оно может быть повторно использованно другим запросом.
2. Казалось бы да, 3500 RPS это не много, но не забываем что на тестовой машине было задействовано всего одно ядро. И один worker-процесс NGINX (которому ещё и TLS делать надо) делил CPU с Тарантулом.
Если выделить NGINX побольше ядер (например 30), и освободить как минимум одно ядро для Тарантула, то можно получить существенно более радостную картину:
Requests/sec: 54746.21
*nginx грузит ~5-87% CPU
*Tarantool грузит ~135% CPU
+1
Возьмите github.com/tarantool/nginx_upstream_module.
Именно его принято использовать при построении сервисов на базе тарантула и nginx-а. И главное — появится возможность управлять конектами к тарантулам в секции upstream и не писать все это самому, ведь в продакшене вы наверняка захотите работать с пачкой тарантулов, чтобы было распределение нагрузки между ними, failover и прочие фишки, которые есть у nginx upstream-ов.
Именно его принято использовать при построении сервисов на базе тарантула и nginx-а. И главное — появится возможность управлять конектами к тарантулам в секции upstream и не писать все это самому, ведь в продакшене вы наверняка захотите работать с пачкой тарантулов, чтобы было распределение нагрузки между ними, failover и прочие фишки, которые есть у nginx upstream-ов.
+3
Sign up to leave a comment.
Сравнительное нагрузочное тестирование Lua-коннекторов для Tarantool из NGINX