Событие Loop против многопоточной блокировки IO

Я читал комментарий о архитектуре сервера.

http://news.ycombinator.com/item?id=520077

В этом комментарии человек говорит 3 вещи:

Цикл событий снова и снова показывался по-настоящему сияющим для большого количества подключений с низкой активностью.
Для сравнения, блокирующая IO-модель с потоками или процессами снова и снова показывала сокращение времени ожидания для каждого запроса по сравнению с циклом события.
В слегка загруженной системе разница неразличима. Под нагрузкой большинство циклов событий выбирают замедлить работу, большинство блокирующих моделей выбирают загрузку.

Являются ли они истинными?

И еще одна статья, озаглавленная "Почему события - плохая идея (для серверов с высоким concurrency)"

http://www.usenix.org/events/hotos03/tech/vonbehren.html

Ответ 1

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

Сначала создайте N потоков, где N == количество ядер/процессоров на вашем компьютере. Каждый поток будет иметь список асинхронных сокетов, которые он должен обрабатывать.
Затем для каждого нового соединения от акцептора "load-balance" новый сокет для потока с наименьшим сокетом.
Внутри каждого потока используйте модель на основе событий для всех сокетов, так что каждый поток может фактически обрабатывать несколько сокетов "одновременно".

При таком подходе

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

Ответ 2

Не уверен, что вы подразумеваете под "низкой активностью", но я считаю, что основным фактором будет то, что вам действительно нужно делать для обработки каждого запроса. Предполагая однопоточный цикл событий, никакие другие клиенты не будут обрабатывать свои запросы во время обработки текущего запроса. Если вам нужно делать много вещей, чтобы обрабатывать каждый запрос ( "много" означает что-то, что требует значительного количества процессоров и/или времени), и предполагая, что ваша машина действительно может эффективно выполнять многозадачность (что время не означает ожидания общей ресурс, как один процессор или аналогичный процессор), вы получите лучшую производительность при многозадачности. Многозадачность может представлять собой многопоточную блокирующую модель, но также может быть циклом событий с одним заданием, который собирает входящие запросы, обрабатывая их многопоточным рабочим factory, который будет обрабатывать их по очереди (через многозадачность) и отправляет вам ответ ASAP.

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