Event Loop vs Многопоточная блокировка ввода-вывода

Question

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

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

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

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

Является ли что-нибудь из этого истинным?

А также еще одна статья под названием «Почему события - плохая идея (для серверов с высоким уровнем параллелизма)»

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

Answer 1

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

1. Сначала создайте N потоков, где N == количество ядер / процессоров на вашем компьютере. Каждый поток будет иметь список асинхронных сокетов, которые он должен обрабатывать.
2. Затем для каждого нового соединения от акцептора «балансировка нагрузки» нового сокета в поток с наименьшим количеством сокетов.
3. В каждом потоке используйте основанную на событиях модель для всех сокетов, чтобы каждый поток мог обрабатывать несколько сокетов «одновременно».

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

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

Answer 2

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

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