2016-08-21 2 views
2

Я пытаюсь определить, является ли это честным эталоном. Цель состоит в том, чтобы увидеть, сколько одновременных соединений с полезными нагрузками различного размера может обрабатывать Node.JS. Код ниже.Простой Node.JS Benchmark

var express = require('express'); 
var Sequelize = require('sequelize'); 
var fs = require('fs'); 
var app = express(); 


var data; 

var filename = process.argv[2] || './start.json'; 
console.log("Using: " + filename); 
data = fs.readFileSync(filename); 

var blockSize = 250000; 
app.get('/start', function (req, res) { 
    // Break up data in blocks. Works to super high concurrents. 
    // for(var i = 0; i < data.length; i+=blockSize) 
    // res.write(data.slice(i, i+blockSize)); 

    // Can only handle about 600 concurrent requests if datasize > 500KB 
    res.send(data); 
}); 



app.listen(3000, function() { 
    console.log('Listing on 3000.'); 
}); 

Как указано в комментариях, если размер полезной нагрузки больше, чем около 500 КБ и там есть 500 будет конкуренты сделать получить «сброс соединения по равному» на клиенте нагрузочного тестирования. Если вы перерезаете данные и напишите их в кусках, он сможет выжить до гораздо более высоких контуров до того, как это начнется. Как исходный узел, так и экспресс демонстрируют такое поведение.

+0

Проблема большая часть данных находится в ОЗУ. Таким образом, для больших полезных нагрузок это сводится к тому, сколько времени потребуется для memcpy(). Это именно те виды рабочей нагрузки, с которыми узел плохо справляется. Узел оптимизирован для ввода-вывода, а не для обработки ОЗУ. Вы получите гораздо лучший параллелизм, открывающий файл как поток чтения и передающий его клиенту. Это приведет к смещению почти всей нагрузки на ОС вместо узла, а если вы находитесь в Linux или Solaris, вы получите огромный импульс от драйверов оптимизированной файловой системы. – slebetman

+0

С другой стороны, для небольших полезных нагрузок вы часто получаете лучшую производительность, сохраняя данные в ОЗУ. Так что это действительно так. – slebetman

+0

Процессор привязывается к 100%, когда размер данных больше, что для узла явно плохо. –

ответ

1
data = fs.readFileSync(filename); 

Методы синхронизации - это убийцы nodejs. Он фактически блокирует цикл события для . ВСЕ требуют, чтобы выступления действительно были очень плохими.

Попробуйте это:

var express = require('express'); 
var Sequelize = require('sequelize'); 
var fs = require('fs'); 
var app = express(); 
var filename = process.argv[2] || './start.json'; 

var blockSize = 250000; 
app.get('/start', function (req, res) { 
    // Break up data in blocks. Works to super high concurrents. 
    // for(var i = 0; i < data.length; i+=blockSize) 
    // res.write(data.slice(i, i+blockSize)); 

    // Can only handle about 600 concurrent requests if datasize > 500KB 
    console.log("Using: " + filename); 

    fs.readFile(filename, function (err, data) { 
     if (err) throw err; 
     res.send(data); 
    }); 

}); 



app.listen(3000, function() { 
    console.log('Listing on 3000.'); 
}); 
+0

Если вы заметили, что это происходит при запуске скрипта ровно один раз. Дело не в контроле загрузки файла - только в передаче. Таким образом, данные хранятся в памяти до того, как сервер даже прослушает соединения. –

0

В качестве альтернативы, вы можете создать поток для чтения и трубы его, вот пример, основанный на коде

var express = require('express'); 
var fs = require('fs'); 
var app = express(); 

var data; 

var filename = process.argv[2] || './data.json'; 
console.log("Using: " + filename); 
data = fs.readFileSync(filename); 

var readStream = fs.createReadStream(filename); 

app.get('/start', function (req, res) { 
    // Can only handle about 600 concurrent requests if datasize > 500KB 
    //res.send(data); 
    readStream.pipe(res); 
}); 
+0

Это была другая идея, которую я имел. Основываясь на том, как он работает, я готов поспорить, что send() делает это за кулисами. Если вы поместите создание readStream в/start, он выполняет точно так же, как отправка необработанного потока. –

+0

бывает. Я тестировал оба решения с очень похожими результатами. –

+1

Кроме того, даже смешнее, если вы делаете большой файл (30 МБ), это даже лучше, чем Go в том же тесте. Неожиданно. –