Будет ли запуск node.js с Apache причиной слишком сильного снижения производительности? - PullRequest
5 голосов
/ 07 ноября 2011

Я пытаюсь запустить Apache и node.js на одном и том же экземпляре Amazon EC2.После исследования в Интернете я нашел следующее решение:

  1. запустить Apache на порту 9000

  2. запустить приложения node.js на порту 8001,8002 и т. Д.

  3. создайте обратный прокси в файле node.js, работающем на порту 80. Он направляет запросы в разные порты на основе имени хоста.

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

Спасибо,

Ответы [ 2 ]

7 голосов
/ 02 декабря 2011

снижение производительности

Наоборот. Если все, что вы делаете с узлом, является прокси, перегрузка незначительна (по сравнению с Apache). У меня есть настройки, аналогичные вашей (небольшая виртуальная машина, 3 устаревших веб-сайта Apache, проксирование и расширение node.js). До сих пор apache является источником ресурсов, а не приложениями моего узла, которые, тем не менее, прокси / фильтруют / перехватывают каждый входящий http-запрос

Вот мои настройки:

главный прокси

, который обрабатывает все входящие запросы (для любого количества доменов): я лично использую http-proxy nodejitsu, который очень надежен и прост в настройке

var http = require('http');
var httpProxy = require('http-proxy');
var options = {

  hostnameOnly: true,
  router: {    
    'domain1.com': '127.0.0.1:8081',
    'www.domain1.com': '127.0.0.1:8081',
    'subdomain1.domain1.com': '127.0.0.1:8082',
(...)
    'domain2.com': '127.0.0.1:8090',
(...)

   }
}

var mainProxy = httpProxy.createServer(options);
mainProxy.listen(8080);

Вы можете перенаправить на apache напрямую из объекта option или выполнить еще один разбор URL-адреса в другом (промежуточном) приложении узла на другом порту.

ПРЕДУПРЕЖДЕНИЕ : если вы не хотите устанавливать / запускать узел как «root» (что я настоятельно рекомендую в производственной среде): перенаправьте порт 80 на другой порт с помощью директивы IPTABLE (скажем, 8080), где работает этот прокси (см. здесь подробный пример директив Iptable ). Мой, на сжатии Debian, читает:

#REDIRECT port 80 to 8080
$IPTABLES -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080

узел приложений

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

Daemonisation

Есть несколько решений, чтобы заставить узел работать как демон. Мои любимые два:

  • nodemon будет отслеживать все файлы в папке и подпапке приложения вашего узла на предмет изменений и перезапускать приложение узла при изменении файла. Идеально подходит для среды разработки
  • forever (еще раз по Nodejitsu) перезапустит приложение вашего узла, если оно когда-либо остановится. Это очень настраиваемый.

Также:

  • сценарий init.d : я написал этот сценарий debian init.d для своих собственных серверов (должен работать в Ubuntu)
1 голос
/ 08 ноября 2011

Узел действительно очень быстрый, и он построен для одновременной обработки тысяч соединений, поэтому, на мой взгляд, использование встроенного прокси-сервера вообще не будет проблемой.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...