Масштабирование nginx со статическими файлами - непостоянные запросы убивают требования

Работаем над проектом, в котором нам нужно на сервере небольшой статический xml-файл ~40k / s.

Все входящие запросы отправляются на сервер из HAProxy. Однако ни один из запросов не будет постоянным.

Проблема заключается в том, что при сравнении с непостоянными запросами экземпляр nginx достигает 19 114 запросов / с. Когда постоянные соединения включены, производительность увеличивается почти на порядок, до 168 867 рэк / с. Результаты схожи с G-wan.

При тестировании непостоянных запросов загрузка ЦП минимальна.

Что я могу сделать, чтобы увеличить производительность с непостоянными соединениями и nginx?

[root@spare01 lighttpd-weighttp-c24b505]# ./weighttp -n 1000000 -c 100 -t 16 "http://192.168.1.40/feed.txt"
finished in 52 sec, 315 millisec and 603 microsec, 19114 req/s, 5413 kbyte/s
requests: 1000000 total, 1000000 started, 1000000 done, 1000000 succeeded, 0 failed, 0 errored
status codes: 1000000 2xx, 0 3xx, 0 4xx, 0 5xx
traffic: 290000000 bytes total, 231000000 bytes http, 59000000 bytes data




[root@spare01 lighttpd-weighttp-c24b505]# ./weighttp -n 1000000 -c 100 -t 16 -k "http://192.168.1.40/feed.txt"
finished in 5 sec, 921 millisec and 791 microsec, 168867 req/s, 48640 kbyte/s
requests: 1000000 total, 1000000 started, 1000000 done, 1000000 succeeded, 0 failed, 0 errored
status codes: 1000000 2xx, 0 3xx, 0 4xx, 0 5xx
traffic: 294950245 bytes total, 235950245 bytes http, 59000000 bytes data
Источник

1 ответ

Решение

Ваши 2 теста похожи (кроме HTTP Keep-Alives):

 ./weighttp -n 1000000 -c 100 -t 16 "http://192.168.1.40/feed.txt"
 ./weighttp -n 1000000 -c 100 -t 16 -k "http://192.168.1.40/feed.txt"

А тот, у кого HTTP Keep-Alives, в 10 раз быстрее:

finished in 52 sec, 19114 req/s, 5413 kbyte/s
finished in 5 sec, 168867 req/s, 48640 kbyte/s

Первый, HTTP Keep-Alives (постоянные соединения) заставляют HTTP-запросы выполняться быстрее, потому что:

  • Без HTTP Keep-Alivesклиент должен установить новое СОЕДИНЕНИЕ для КАЖДОГО запроса (это медленно из-за TCP-квитирования).

  • С HTTP Keep-Alivesклиент может отправлять все запросы одновременно (используя ОДНО ЖЕ СОЕДИНЕНИЕ). Это быстрее, потому что есть меньше вещей, чтобы сделать.

Во-вторых, вы говорите, что размер статического файла XML "маленький".

Является ли "маленький" ближе к 1 КБ или 1 МБ? Мы не знаем Но это имеет огромное значение с точки зрения доступных опций для ускорения вещей.

Огромные файлы обычно проходят через sendfile() потому что он работает в ядре, освобождая сервер пользовательского режима от бремени чтения с диска и буферизации.

Небольшие файлы могут использовать более гибкие параметры, доступные для разработчиков приложений в пользовательском режиме, но и здесь размер файла имеет значение (байты и килобайты - это разные животные).

В-третьих, вы используете 16 потоков с вашим тестом. Вы действительно наслаждаетесь 16 PHYSICAL CPU Cores на ОБА клиент и сервер машины?

Если это не так, то вы просто замедляете тест до такой степени, что больше не тестируете веб-серверы.

Как видите, на производительность влияют многие факторы. Есть и другие настройки ОС (параметры стека TCP, доступные дескрипторы файлов, системные буферы и т. Д.).

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

Источник
Другие вопросы по тегам