Комментарии 29
НЛО прилетело и опубликовало эту надпись здесь
А чем стандартный http не устроил, если так важна производительность?
Так как же теперь с потреблением памяти? Без заключительного абзаца неясно стоила ли овчинка выделки. Желательно с цифрами. Спасибо.
Потребление памяти уменьшилось ( еще сильнее оно уменьшилось при использовании ручной сборки мусора )
Сейчас провел маленький тест — 300 запросов на habrahabr.ru
Вот числа:
Request — { rss: 71733248, heapTotal: 57203968, heapUsed: 25940592 }
tiny_request — { rss: 46379008, heapTotal: 47928576, heapUsed: 11682480 }
Сейчас провел маленький тест — 300 запросов на habrahabr.ru
Вот числа:
Request — { rss: 71733248, heapTotal: 57203968, heapUsed: 25940592 }
tiny_request — { rss: 46379008, heapTotal: 47928576, heapUsed: 11682480 }
Посмотрите в сторону functional programming (например rxjs), чтобы избавиться от бойлерплейта 'if (!err && response.statusCode == 200) {'
Я бы предпочел видеть API в таком виде:
Я бы предпочел видеть API в таком виде:
req
.post(...)
.onOk((body, response) -> console.log(body))
.onStatus(404, () -> ...)
Знаете про superagent?
А кто-то предпочёл бы увидеть следующее:
req.post(...).then(...)
req.post(...).then(...)
А кто-то и подавно
:)
let response = await req.post(...);
if (response.statusCode === 404) {
...
}
console.log(response.body);
...
:)
co + promises
Именно их и использовал долгое время, но они все равно создают лишний шум в коде, так что теперь babel «es7.asyncFunctions» + promises — наше все.
bluebird.coroutine быстрее ;)
А чем не понравился, например, got?
Зачем писать в 2015 без Promise API? Возьмите node-fetch.
А вы думаете, что будущее за Promise API? Мое мнение, что нет и даже не за асинхронной архитектурой. Недавно было интересно тестануть nodejs на потребление памяти при постоянной нагрузки, и честно говоря классическая связка php/nginx — выигрывает в разы по производительности и по потреблению памяти. Nodejs использую только как commit-server не более того.
PS: было бы хорошо если бы кто-нибуть написал статью со статистикой потребления памяти при нагрузках с использованием разных сервисов (http,https,ssh и т.д.)
PS: было бы хорошо если бы кто-нибуть написал статью со статистикой потребления памяти при нагрузках с использованием разных сервисов (http,https,ssh и т.д.)
Если php+nginx выигрывает в разы, то вы что-то делаете не так. Априори, пересоздаваемое окружение на каждый запрос вместе с блокировкой ввода-вывода будет медленнее, чем горячая точка входа и неблокирующее I/O. Ну а асинхронная архитектура имеет и плюсы, и минусы. Например, в том же сравнении php+nginx и node.js (если использовать везде 1 процесс) node.js будет быстрее, так как не будет блокировки из-за I/O.
Про PS вообще не понял что вы имеете ввиду. Потребление памяти не зависит от языка, на котором решается задача. Это зависит только от задачи и от качества написанного кода.
1. Делать err третьим параметром в callback, мягко говоря, не принято. Лучше ставить параметры в порядке убывания их важности и частоты использования: callback(err, response, body). Тут даже response важнее body, потому, что к response.statusCode точно обратятся, а к body только условно. Но это уже не так критично, главное err поставьте первым.
2. Тип ответа JSON можно не задавать, а определять по Content-Type: application/json или application/javascript (если поддерживать JSONP). А функции для парса данных разных типов можно примешивать к response. Например, так выглядит компактнее:
3. Иметь параметры для всего именованные параметры хорошо, но альтернативно задавать все в URL намного компактнее:
Вместо: req.get({ url: 'http://test.com', query: { test: 'test' }, port: 8080}, callback);
Делать: req.get('http://test.com:8080?test=test', callback);
Да и часто все это у нас уже есть в виде одной строки URL, а тут ее парсить и потом Вы ее опять склеите же.
2. Тип ответа JSON можно не задавать, а определять по Content-Type: application/json или application/javascript (если поддерживать JSONP). А функции для парса данных разных типов можно примешивать к response. Например, так выглядит компактнее:
req.get('http://test.com/json, function(err, res) {
if (!err && res.statusCode === 200) {
// можем брать res.asJSON()
// можем брать res.asBuffer() или res.asString()
}
});
3. Иметь параметры для всего именованные параметры хорошо, но альтернативно задавать все в URL намного компактнее:
Вместо: req.get({ url: 'http://test.com', query: { test: 'test' }, port: 8080}, callback);
Делать: req.get('http://test.com:8080?test=test', callback);
Да и часто все это у нас уже есть в виде одной строки URL, а тут ее парсить и потом Вы ее опять склеите же.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Легковесный модуль для HTTP запросов