Eventloop имеет высокую нагрузку ksoftirqd; nginx не выполняет одни и те же системные вызовы. Зачем?

Ответ 1

Короткий ответ:
Иногда быть быстрее означает медленнее.

Длинный ответ:

В настройке с одним запросом (по одному запросу одновременно) epoll_wait всегда блокирует и заставляет контекстный переключатель. Клиент (ab в этом случае) должен получить и обработать ответ + отправить следующий запрос до того, как сервер снова epoll_wait а epoll_wait вернет ожидающий сокет. Скорость, с которой сервер генерирует ответ, не изменяет это поведение, так как клиент всегда ожидает ответа сервера перед отправкой следующего запроса.

В настройке с несколькими запросами это зависит от производительности сервера, если epoll_wait заставляет контекстный переключатель или нет. Если сервер-приложение работает медленнее, вероятность того, что следующий запрос уже ожидает, выше; в этом случае переключение контекста не требуется, поскольку epoll_wait может немедленно вернуться. Переключатель контекста является дорогостоящим и может занять больше времени, чем требуется следующий запрос, чтобы получить тратить время.

Я понял это, когда исключил вероятность того, что epoll_wait сделает контекст-переключатель, установив тайм-аут на ноль. Это заставляет epoll_wait немедленно возвращаться, даже если нет ожидающего запроса (поэтому он никогда не ждет и, следовательно, нет принудительного контекстного переключателя). В этом случае способ тестового приложения превосходит nginx даже в настройке с несколькими запросами.

Я еще раз подтвердил свою теорию:

• удаление работы из nginx (отключение журнала доступа), что сделало его медленнее
• добавив работу в тестовое приложение (spin-loop), которое ускорило работу

в настройке с несколькими запросами.

Для этого ответа я повторил все измерения. Все тесты выполнялись на обновленной ubuntu-коробке с 8 ядрами (более 5) с сервером и клиентом, работающим на этой машине в одно и то же время. Тест-приложение не изменилось.

• gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0
• Версия nginx: nginx/1.14.0 (Ubuntu)

Я написал небольшой сценарий, чтобы придумать запрос/второе число ниже, которое запускает ab с 60 000 запросами в 100 раз, получая самый быстрый результат.

maxRequests=0
for ((i = 0; i < 100; ++i)); do
    requests=$(ab -n 60000 -c (1 or 4) http://127.0.0.1:8081/index.html 2>&1 | grep "Requests per second" | cut -d" " -f7)
    requests=${requests%.*}
    maxRequests=$(( maxRequests > requests ? maxRequests : requests ))
done
echo ${maxRequests}

Здесь снова базовые значения с теми же настройками, что и в вопросе.

Requests per second: 13507 (test-application, 1c)
Requests per second: 27648 (test-application, 4c)
Requests per second: 11755 (nginx, 1c)
Requests per second: 31446 (nginx, 4c)

Чтобы сделать nginx быстрее (и, следовательно, медленнее с 4c), я отключил журнал доступа.

Requests per second: 12028 (nginx, 1c, no access-log)
Requests per second: 28976 (nginx, 4c, no access-log)

Вот результат, если тестовое приложение никогда не спит по настройкам epool_wait - время до нуля.
Интересно, что разница в настройке 1c показывает, сколько стоит пробуждение тестового приложения при поступлении нового запроса.

Requests per second: 20079 (test-application, 1c, spinning)
Requests per second: 34522 (test-application, 4c, spinning)

Для этих последних измерений я добавил некоторую работу на тестовое приложение, сделав его искусственно медленнее, чтобы увеличить вероятность предотвращения контекстного переключения. Я добавил код ниже в конец внутреннего цикла for (после close) и изменил начальное значение j чтобы получить разные результаты

uint8_t j = 50;
while (--j != 0) {
    uint8_t i = 0;
    while (--i != 0)
        asm("");
}

Requests per second: 12910 (test-application, 1c, j=50)
Requests per second: 12126 (test-application, 1c, j=100)
Requests per second: 11634 (test-application, 1c, j=150)
Requests per second: 11020 (test-application, 1c, j=200)
Requests per second: 10235 (test-application, 1c, j=250)
Requests per second: 27447 (test-application, 4c, j=25)
Requests per second: 29464 (test-application, 4c, j=50)
Requests per second: 31334 (test-application, 4c, j=75)
Requests per second: 32079 (test-application, 4c, j=100)
Requests per second: 33510 (test-application, 4c, j=125)
Requests per second: 34241 (test-application, 4c, j=150)
Requests per second: 34189 (test-application, 4c, j=175)
Requests per second: 33855 (test-application, 4c, j=200)
Requests per second: 33328 (test-application, 4c, j=250)