这里就经由master来掌控全局了. 当一个皇帝(worker)正在宠幸妃子的时候，master就会安排剩下的几个皇帝排队一个几个的来。 其实中间的handle就会我们具体的业务逻辑. 如同:app.js.
ok~ 我们再来看一下cluster模块实现多进程的具体写法.
cluster模块实现多进程
现在的cluster已经可以说完全做到的负载均衡。在cluster说明我已经做了阐述了。我们来看一下具体的实现吧
var cluster = require('cluster'); var http = require('http'); var numCPUs = require('os').cpus().length; if (cluster.isMaster) { console.log('[master] ' + "start master..."); for (var i = 0; i < numCPUs; i++) { cluster.fork(); } cluster.on('listening', function (worker, address) { console.log('[master] ' + 'listening: worker' + worker.id + ',pid:' + worker.process.pid + ', Address:' + address.address + ":" + address.port); }); } else if (cluster.isWorker) { console.log('[worker] ' + "start worker ..." + cluster.worker.id); var num = 0; http.createServer(function (req, res) { num++; console.log('worker'+cluster.worker.id+":"+num); res.end('worker'+cluster.worker.id+',PID:'+process.pid); }).listen(3000); }
这里使用的是HTTP模块，当然，完全也可以替换为socket模块. 不过由于这样书写，将集群和单边给混淆了。 所以，推荐写法是将具体业务逻辑独立出来.
var cluster = require('cluster'); var numCPUs = require('os').cpus().length; if (cluster.isMaster) { console.log('[master] ' + "start master..."); for (var i = 0; i < numCPUs; i++) { cluster.fork(); } cluster.on('listening', function (worker, address) { console.log('[master] ' + 'listening: worker' + worker.id + ',pid:' + worker.process.pid + ', Address:' + address.address + ":" + address.port); }); } else if (cluster.isWorker) { require('app.js'); } //app.js就是开启具体的业务逻辑了 //app.js具体内容 const net = require('net'); //自动创建socket const server = net.createServer(function(socket) { //'connection' listener socket.on('end', function() { console.log('server disconnected'); }); socket.on('data', function() { socket.end('hello\r\n'); }); }); //开启端口的监听 server.listen(8124, function() { //'listening' listener console.log('working') });
接着我们开启服务，node master.js
然后进行测试
siege -c 100 -r 2 :8124
我这里开启的是长连接. 每个worker处理的长连接数是有限的。所以，当有额外的连接到来时，worker会断开当前没有响应的连接，去处理新的连接。
不过，平常我们都是使用HTTP开启 短连接，快速处理大并发的请求。
这是我改成HTTP短连接之后的结果
Transactions: 200 hits Availability: 100.00 % Elapsed time: 2.09 secs Data transferred: 0.00 MB Response time: 0.02 secs Transaction rate: 95.69 trans/sec Throughput: 0.00 MB/sec Concurrency: 1.74 Successful transactions: 200 Failed transactions: 0 Longest transaction: 0.05 Shortest transaction: 0.02
那，怎么模拟大并发嘞？
e e e e e e e e e ...
自己解决啊~
开玩笑的啦~ 不然我写blog是为了什么呢？ 就是为了传播知识.
在介绍工具之前，我想先说几个关于性能的基本概念
QPS(TPS),并发数,响应时间,吞吐量,吞吐率
你母鸡的性能测试theories
自从我们和服务器扯上关系后,我们前端的性能测试真的很多。但这也是我们必须掌握的tip. 本来前端宝宝只需要看看控制台，了解一下网页运行是否运行顺畅, 看看TimeLine，Profile 就可以了。 不过，作为一名有追求，有志于改变世界的童鞋来说。。。
md~ 又要学了...
ok~ 好了，在进入正题之前，我再放一次 线上的测试结果.
Transactions: 200 hits Availability: 100.00 % Elapsed time: 13.46 secs Data transferred: 0.15 MB Response time: 3.64 secs Transaction rate: 14.86 trans/sec Throughput: 0.01 MB/sec Concurrency: 54.15 Successful transactions: 200 Failed transactions: 0 Longest transaction: 11.27 Shortest transaction: 0.01
根据上面的数据，就可以得出，你网页的大致性能了。
恩~ let's begin
吞吐率
关于吞吐率有多种解读，一种是:描绘web服务器单位时间处理请求的能力。根据这个描述,其单位就为: req/sec. 另一种是: 单位时间内网络上传输的数据量。 而根据这个描述的话,他的单位就为: MB/sec.
而这个指标就是上面数据中的Throughput. 当然，肯定是越大越好了
吞吐量
这个和上面的吞吐率很有点关系的。 吞吐量是在没有时间的限制下，你一次测试的传输数据总和。 所以，没有时间条件的测试，都是耍流氓。
这个对应于上面数据中的Data transferred.
事务 && TPS