Почему основанные на событиях сетевые приложения по своей природе быстрее, чем потоковые?

Question

Мы все ознакомились с тестами и знаем факты - асинхронные сетевые серверы на основе событий работают быстрее, чем их многопоточные аналоги. Подумайте lighttpd или Зевс против Apache или IIS Почему это так?

Answer 1

Я думаю, что вопрос, основанный на событиях, на основе потоков - это не вопрос - это неблокирующий мультиплексированный ввод / вывод, выбираемые сокеты, решение против решения с пулом потоков.

В первом случае вы обрабатываете все входящие данные, независимо от того, что их использует - поэтому нет блокировок на чтение - один «слушатель». Один поток слушателя передает данные в рабочие потоки разных типов, а не в один для каждого соединения. Опять же, никаких блокировок при записи каких-либо данных, поэтому обработчик данных может просто работать с ним отдельно. Поскольку это решение в основном для операций чтения / записи ввода-вывода, оно не занимает много процессорного времени, поэтому ваше приложение может делать это так, как хочет.

В решении с пулом потоков у вас есть отдельные потоки, обрабатывающие каждое соединение, поэтому им приходится совместно использовать время для включения и выключения контекста для каждого «прослушивания». В этом решении операции CPU + IO находятся в том же потоке, который получает интервал времени, так что вы в конечном итоге ожидаете завершения операций ввода-вывода для каждого потока (блокирование), что обычно может выполняться без использования времени CPU.

Google для неблокирующего ввода-вывода для более подробной информации - и вы также можете найти некоторые сравнения с пулами потоков.

(если кто-то может уточнить эти моменты, не стесняйтесь)

Answer 2

Управляемые событиями приложения не по своей природе быстрее.

С Почему события плохая идея (для серверов с высоким уровнем параллелизма) :

We examine the claimed strengths of events over threads and show that the
weaknesses of threads are artifacts of specific threading implementations
and not inherent to the threading paradigm. As evidence, we present a
user-level thread package that scales to 100,000 threads and achieves
excellent performance in a web server.

Это было в 2003 году. Конечно, с тех пор состояние многопоточности в современных ОС улучшилось.

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

Это также означает, что вы получаете все возможные совместные многозадачности. Если по какой-либо причине одному из ваших обработчиков событий требуется некоторое время, он останавливает поток событий. Абсолютно несвязанные запросы запаздывают. Чтобы избежать этого, даже длительные операции с ЦП должны быть отправлены куда-то еще. Когда вы говорите о ядре сервера с высокой степенью параллелизма, «длительная операция» - это относительный термин, порядка микросекунд для сервера, который должен обрабатывать 100 000 запросов в секунду. Я надеюсь, что системе виртуальной памяти никогда не придется извлекать страницы с диска за вас!

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

Пара важных вопросов для автора нового серверного приложения:

• Как потоки работают на платформах, которые вы намереваетесь поддерживать сегодня? Они станут твоим узким местом?
• Если вы все еще застряли с плохой реализацией потока: почему никто не исправляет это?

Answer 3

Это действительно зависит от того, что вы делаете; программирование на основе событий, безусловно, сложно для нетривиальных приложений. Быть веб-сервером - действительно очень простая и понятная проблема, и модели, основанные на событиях, и многопоточные модели работают очень хорошо в современных ОС.

Правильная разработка более сложных серверных приложений в модели событий, как правило, довольно сложна - многопоточные приложения гораздо проще писать. Это может быть решающим фактором, а не производительность.

Answer 4

Это не о потоках на самом деле. Речь идет о том, как потоки используются для обслуживания запросов. Для чего-то вроде lighttpd у вас есть один поток, который обслуживает несколько соединений через события. Для более старых версий apache у вас был процесс на соединение, и процесс просыпался от входящих данных, поэтому вы получали очень большое число при большом количестве запросов. Однако теперь с MPM apache также основан на событиях, см. apache MPM event .