Что конкретно делает Node.js более масштабируемым, чем Apache?

Я обнаружил, что это сообщение в блоге Томислава Капана объясняет это очень хорошо:
Почему ад я использовал бы Node.js? Поэтапное введение

Моя интерпретация его сущности, для Node 0.10, по сравнению с Apache:

Хорошие детали

• Node.js избегает разворота потоков для каждого запроса или не требует обработки пула запросов к набору таких потоков, как Apache. Поэтому он имеет меньше накладных расходов для обработки запросов и отличается быстрым ответом.
• Node.js может делегировать выполнение запроса отдельному компоненту и сосредоточиться на новых запросах до тех пор, пока делегированный компонент не вернется с обработанным результатом. Это асинхронный код и становится возможным благодаря модели событий. Apache выполняет запросы в последовательном порядке в пуле и не может повторно использовать поток, когда один из его модулей просто ждет завершения задачи. Затем Apache отправляет запросы в очередь, пока поток в пуле снова не станет доступен.
• Node.js говорит JavaScript, и поэтому очень быстро проходит и обрабатывает JSON, извлекаемый из внешних источников веб-API, таких как MongoDB, что сокращает время, необходимое для каждого запроса. Модулям Apache, таким как PHP, может потребоваться больше времени, потому что они не могут эффективно анализировать и манипулировать JSON, потому что для обработки данных они нуждаются marshalling.

Плохие части

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

• Node.js отстой в задачах с интенсивным вычислением, потому что всякий раз, когда он делает что-то долгое время, он ставит в очередь все остальные входящие запросы из-за единственного потока. Apache, как правило, имеет больше потоков, и ОС будет аккуратно и справедливо планировать время процессора между этими потоками, все еще позволяя обрабатывать новые потоки, хотя и немного медленнее. За исключением случаев, когда все доступные потоки в Apache обрабатывают запросы, Apache также запускает запросы на очередность.
• Node.js не полностью использует многоядерные процессоры, если только вы не создаете кластер Node.js или не переверните дочерние процессы. По иронии судьбы, если вы делаете последние два, вы можете добавить еще более сложную задачу, такую ​​же проблему, что и Apache. Логически вы могли бы также развернуть больше процессов Node.js, но это не управляется Node.js. Вам нужно будет проверить свой код, чтобы увидеть, что работает лучше; 1) многопоточность из Node.js с кластерами и дочерними процессами или 2) несколько процессов Node.js.

смягчающих

Все серверные платформы имеют верхний предел. Node.js и Apache оба достигнут его в какой-то момент.

• Node.js достигнет его самого быстрого, когда у вас будут сложные вычислительные задачи.
• Apache быстрее достигнет его, когда вы бросаете тонны небольших запросов, требующих длительного последовательного исполнения.

Три вещи, которые вы могли бы сделать, чтобы увеличить пропускную способность Node.js

• Используйте многоядерные процессоры, создав cluster, используйте дочерние процессы или использовать многопроцессорный оркестр, например Phusion Passenger.
• Установить рабочие роли, связанные с очередью сообщений. Это будет наиболее эффективное решение для запросов с интенсивным вычислением с интенсивным вычислением; выгрузите их на рабочую ферму. Это позволит разделить ваши серверы на две части; 1) публичные клиринговые серверы, которые принимают запросы от пользователей, и 2) серверы частных работников, которые выполняют длительные задачи. Оба связаны с очередью сообщений. Клеркие серверы добавляют в очередь сообщения (входящие длительные запросы). Рабочие роли прослушивают входящие сообщения, обрабатывают их и могут возвращать результат в очередь сообщений. Если требуется запрос/ответ, администратор может асинхронно дождаться, когда ответное сообщение поступит в очередь сообщений. Примеры очередей сообщений RabbitMQ и ZeroMQ.
• Установите балансировщик нагрузки и увеличьте количество серверов. Теперь, когда вы эффективно используете оборудование и делегируете длительные задачи, вы можете масштабировать горизонтально. Если у вас есть балансировщик нагрузки, вы можете добавить дополнительные серверы. Используя очередь сообщений, вы можете добавить больше рабочих серверов. Вы могли бы даже настроить это в облаке, чтобы вы могли масштабироваться по требованию.

Это зависит от того, как вы его используете. Node.js по умолчанию является однопоточным, но с использованием (относительно) нового кластерного модуля вы можете масштабировать горизонтально по нескольким потокам.

Кроме того, ваши потребности в базе данных также будут определять, насколько эффективным является масштабирование с помощью Node. Например, использование MySQL с Node.js не принесет вам почти такой же пользы, как использование MongoDB, из-за обусловленного событиями характера как MongoDB, так и Node.js.

В следующей ссылке есть много хороших тестов систем с различными настройками: http://www.techempower.com/benchmarks/

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

Опять же, это сильно зависит от ваших потребностей. Я считаю, что если вы просто используете статические веб-сайты, рекомендуется придерживаться более традиционного стека. Однако люди делали некоторые удивительные вещи с помощью Node.js для других нужд: http://blog.caustik.com/2012/08/19/node-js-w1m-concurrent-connections/ (c10k? Ha!)

Изменить: стоит упомянуть, что вы действительно не "заменяете" просто apache Node.js. Вы бы заменили apache и php (в типичном стеке лампы).