Настоящий многопоточный веб-сервер на ассемблере под Linux

Тут и обсуждать нечего, каждый рабочий процесс слушает сокет. Иными словами процессов много и на многоядерной системе они могут исполняться параллельно, а с отключенным accept_mutex-ом accept'ить соединения одновременно. Значит узкое место имеет место быть в ядре, но только вместо его устранения был придуман способ требующий дополнительных усилий со стороны разработчиков, плюс лишающий nginx одного из ключевых преимуществ — обновление версии и конфигурации без потери соединений. Разработчик DragonFlyBSD осознал свою ошибку и ушел править ядро, а когда тем же самым займутся в линуксе — неизвестно.

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

Как утверждает автор:

In case #2, the proportion of connections accepted per thread tends
to be uneven under high connection load (assuming simple event loop:
while (1) { accept(); process() }, wakeup does not promote fairness
among the sockets. We have seen the disproportion to be as high
as 3:1 ratio between thread accepting most connections and the one
accepting the fewest. With so_reusport the distribution is
uniform.

Иначе говоря, с включенной опцией ядро начинает раскладывать соединения по сокетам в равной пропорции, вместо того, чтобы рабочие процессы разбирали из общей копилки по мере необходимости. Хорошо ли это? Как сказать, в случае, когда все соединения эквивалентны (установлены одним клиентом, запрашивают один и тот же ресурс, по одному и тому же каналу), т.е. требуют одинаковых ресурсов на обработку — по идее особой разницы не должно быть, но равномерное распределение видимо улучшает баланс. Именно этот случай и реализует ваш бенчмарк.

Но реальность она чаще всего отличается от этих идеальный условий. Представьте, что на сервер поступают разные по тяжести запросы, легкие, средние и тяжелые. Когда ядро раскладывает соединения, оно не знает, в каком из них будет легкий запрос, а в каком тяжелый, в итоге один воркер может получить много легких запросов и быстро с ними справиться, обслужит всю свою очередь соединений на своем дескрипторе, а затем будет простаивать, в то время как другой всё ещё пыхтит над несколькими тяжелыми запросами. И не только запросы отличаются, отличаются клиенты, один сможет быстро прислать запрос, другой будет слать медленно, пакет за пакетом, один сможет быстро забрать ответ, другой будет вытягивать его долго.