Производительность обратного прокси Nodejs - PullRequest
Новая
       11

Производительность обратного прокси Nodejs

9 голосов
/ 01 ноября 2011

Я изучаю возможность использования Node в качестве обратного прокси.Одна из основных целей моего проекта - обеспечить ОЧЕНЬ высокую производительность.Поэтому я настроил сервер узлов для прокси-запросов к целевому серверу узлов, который будет отвечать «привет мир» независимо от запроса.

Используя Apache Bench, я провел некоторое сравнение по количеству обработанных запросовв секунду.Прокси, цель и вызывающий объект находятся в отдельных экземплярах M1 Large в AWS.Мои результаты разочаровывают и сбивают с толку.

Непосредственно от звонящего к цели: 

ab -c 100 -n 10000 http://target-instance/

= ~ 2600 запросов в секунду

От звонящего через прокси к цели 

ab -c 100 -n 10000 http://proxy-instance/

= ~ 1100 запросов в секунду

Используя lighttpd, я смог получить ~ 3500 запросов в секунду для прокси и цели

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

Вот мой прокси-код вУзел v0.5.9: Я что-то упустил? 

var server =
http.createServer(function(req, res){
    var opts = { host: 'target-instance',
                 port: 80,
                 path: '/',
                 method: 'GET'};
    var proxyRequest = http.get(opts, function(response){
            response.on('data', function(chunk){
                    res.write(chunk);
            });
            response.on('end', function(){
                    res.end()
            });
    });
});
server.listen(80);

Ответы [ 4 ]

8 голосов
/ 12 января 2013

Хотя Node.js очень эффективен, он не является многопоточным, поэтому прокси-узел будет обрабатывать больше соединений, чем целевой, но только с одним потоком, и поэтому станет узким местом. Есть два способа обойти это:

  1. Используйте многопоточный балансировщик нагрузки перед несколькими экземплярами прокси вашего узла (например, nginx).
  2. Измените прокси вашего узла, чтобы использовать несколько процессов . Для этого существует несколько узловых модулей, но теперь узел включает в себя « cluster » из коробки и представляется мне самым простым способом.
3 голосов
/ 01 ноября 2011

Попробуйте бодрый: https://github.com/substack/bouncy

Он был оптимизирован для очень высокой производительности.

0 голосов
/ 02 ноября 2011

после добавления соединения: заголовок keep-alive, вы должны также проверить с помощью keep-alive (опция -k):

ab -c 100 -n 10000 -k http://xxxx/

0 голосов
/ 02 ноября 2011

Из документов http.request:

Отправка «Connection: keep-alive» уведомит узел о том, что соединение с сервером должно быть сохранено до следующего запроса.

Так что, держу пари, ваш прокси-сервер повторно подключается к целевому экземпляру с каждым запросом, что очень неэффективно. Я думаю, что ваша переменная options должна выглядеть так, чтобы ускорить ее: 

var opts  {
    host: 'target-instance',
    port: 80,
    path: '/',
    headers: {
        "Connection": "keep-alive"
    }
};
...