摘要：通過(guò)將的給出來(lái)的進(jìn)程。恩吞吐率關(guān)于吞吐率有多種解讀，一種是描繪服務(wù)器單位時(shí)間處理請(qǐng)求的能力。而根據(jù)這個(gè)描述的話(huà)他的單位就為而這個(gè)指標(biāo)就是上面數(shù)據(jù)中的當(dāng)然，肯定是越大越好了吞吐量這個(gè)和上面的吞吐率很有點(diǎn)關(guān)系的。

首先鄭重聲明:
nodeJS 是一門(mén)單線(xiàn)程!異步!非阻塞語(yǔ)言!
nodeJS 是一門(mén)單線(xiàn)程!異步!非阻塞語(yǔ)言!
nodeJS 是一門(mén)單線(xiàn)程!異步!非阻塞語(yǔ)言!

重要的事情說(shuō)3遍。 因?yàn)閚odeJS天生自帶buff, 所以從一出生就受到 萬(wàn)千 粉絲的追捧(俺，也是它的死忠). 但是，傻逼php 竟然嘲笑 我大NodeJS 的性能。 說(shuō)不穩(wěn)定，不可靠，只能利用單核CPU。 辣雞 nodeJS.
艸!艸!艸!
搞mo shi~
但，大哥就是大哥,nodeJS在v0.8 的時(shí)候就已經(jīng)加入了cluster的模塊。 完全打臉php. 雖然，現(xiàn)在php 也開(kāi)始抄襲nodeJS, 退出php7, 但是，渣渣，你就只會(huì)抄...
233333
對(duì)不起啊，上面是我自已意淫的一段~ 以上內(nèi)容，純屬調(diào)侃，如果雷同，純屬巧合。
Ok~ 我們來(lái)正式介紹一下nodeJS的多進(jìn)程吧~

以前，由于cluster 本身的不完善，可能由于多方面原因吧，實(shí)現(xiàn)性能不好。 結(jié)果是，pm2 包的 崛起。 輕松使用一個(gè)pm2 就可以開(kāi)啟多進(jìn)程，實(shí)現(xiàn)負(fù)載均衡的效果。

pm2 start app.js

pm2的內(nèi)部和cluster內(nèi)部實(shí)現(xiàn)其實(shí)是一個(gè)道理，都是封裝了一層child_process--fork. 而child_process--fork 則是封裝了unix 系統(tǒng)的fork 方法。 既然，都到這了，我們來(lái)看看官方給出的解釋吧。

fork() creates a new process by duplicating the calling process. The new process is referred to as the child process. The calling process is referred to as the parent process.
The child process and the parent process run in separate memory spaces. At the time of fork() both memory spaces have the same content. Memory writes, file mappings (mmap(2)), and unmappings (munmap(2)) performed by one of the processes do not affect the other.

俺來(lái)翻譯一下，fork其實(shí)就是創(chuàng)建子進(jìn)程的方法，新創(chuàng)建的進(jìn)程被認(rèn)為是子進(jìn)程，而調(diào)用fork的進(jìn)程則是父進(jìn)程。 子進(jìn)程和父進(jìn)程本來(lái)是在獨(dú)立的內(nèi)存空間中的。但當(dāng)你使用了fork之后，兩者就處在同一個(gè)作用域內(nèi)了。 但是，內(nèi)存的讀寫(xiě)，文件的map,都不會(huì)影響對(duì)方。

上面那段的意思就是，你創(chuàng)建的進(jìn)程其實(shí)可以相互通信，并且被master進(jìn)程 管理。
看圖~~~

其實(shí)就是這個(gè)意思。
Ok~ 這只是系統(tǒng)創(chuàng)建子進(jìn)程的模型。那么在NodeJs中是怎樣實(shí)現(xiàn)進(jìn)程之間的交互的呢？
很簡(jiǎn)單監(jiān)聽(tīng)端口唄。。。
但是，實(shí)現(xiàn)通信不是很難，關(guān)鍵在于如果分配請(qǐng)求，這一點(diǎn)nodeJS 踩的坑確實(shí)很大。

long time ago

nodeJS的master 開(kāi)始并不是上帝， 他只是一個(gè)小小的太監(jiān)，每次請(qǐng)求(妃子)來(lái)的時(shí)候，他只會(huì)默默的看著幾個(gè)worker小皇帝相互爭(zhēng)奪，如果某個(gè)worker勝出，則其他的worker也就草草了事，等下一個(gè)請(qǐng)求過(guò)來(lái)。所以說(shuō)，每來(lái)一次請(qǐng)求，都會(huì)引起一場(chǎng)腥風(fēng)血雨。而，我們體會(huì)最深的就是驚群現(xiàn)象,即,CPU爆表.
借用TJ大神的一幅圖，說(shuō)明一下。

這里，master只是綁定端口，而不會(huì)對(duì)來(lái)的請(qǐng)求做任何處理。 通過(guò)將socket的fd給fork出來(lái)的進(jìn)程。造成的結(jié)果就是4個(gè)人男人(worker)搶一個(gè)妃子(request). 那場(chǎng)面別提有多血腥了。
前面說(shuō)過(guò)，cluster其實(shí)就是對(duì)child_process的一層封裝，那我們繼續(xù)往底層走一點(diǎn)。實(shí)現(xiàn)cluster多進(jìn)程。 首先，我們需要了解，這幾個(gè)模塊的基本用法。net,child_process.

這個(gè)應(yīng)該是nodeJS 進(jìn)程最核心的模塊。 基本的方法，有幾個(gè)，不過(guò)我這里，只介紹比較核心的:spawn ,fork ,exec。如果大家有興趣，可以去child_process參考.

child_process.spawn(command, args)

該方法用來(lái)運(yùn)行指定的程序。比如: node app.js.他是異步的命令，但不支持callback, 不過(guò)我們可以使用process.on來(lái)監(jiān)聽(tīng)結(jié)果。 他自帶3個(gè)參數(shù).
command: 執(zhí)行命令
args[Array]: 命令所帶的參數(shù)
options[Object]: 環(huán)境變量對(duì)象

OK~ 我們舉個(gè)一個(gè)簡(jiǎn)單的demo: 試一試運(yùn)行 touch apawn.js

const spawn = require("child_process").spawn;
const touch = spawn("touch",["spawn.js"]);

touch.stdout.on("data", (data) => {
  console.log(`stdout: ${data}`);
});

touch.stderr.on("data", (data) => {
  console.log(`stderr: ${data}`);
});

touch.on("close", (code) => {
  console.log(`child process exited with code ${code}`);
});

如果，正確的話(huà)，應(yīng)該會(huì)輸
出child process exited with code 0. 然后運(yùn)行目錄會(huì)生成pawn.js文件。 當(dāng)然，如果你需要運(yùn)行多參數(shù)的命令的話(huà)這就有點(diǎn)蛋疼了。
所以，nodeJS 使用了exec對(duì)其進(jìn)行很好的封裝，而且他支持回調(diào)函數(shù)，這比較能夠讓我們理解。

child_process.exec(order,cb(err[,stdout,stderr]));

order: 就是你執(zhí)行的命令. 比如: rm spawn.js
cb: 就是命令執(zhí)行成功后的回調(diào)函數(shù)。

const childProcess = require("child_process");

const ls = childProcess.exec("rm spawn.js", function (error, stdout, stderr) {
   if (error) {
     console.log(error.stack);
     console.log("Error code: "+error.code);
   }
   console.log("Child Process STDOUT: "+stdout);
});

正常情況下會(huì)刪除spawn.js文件。
上面兩個(gè)只是簡(jiǎn)單的運(yùn)行進(jìn)程的命令。 最后，(Boss總是最后出場(chǎng)的). 我們來(lái)瞧瞧fork方法的使用.
fork其實(shí)也是用來(lái)執(zhí)行進(jìn)程，比如,spawn("node",["app.js"]),其實(shí)和fork("app.js") 是一樣的效果的。但是，fork牛逼的地方在于他在開(kāi)啟一個(gè)子進(jìn)程時(shí)，同時(shí)建立了一個(gè)信息通道(雙工的哦). 倆個(gè)進(jìn)程之間使用process.on("message",fn)和process.send(...)進(jìn)行信息的交流.

child_process.fork(order) //創(chuàng)建子進(jìn)程

worker.on("message",cb) //監(jiān)聽(tīng)message事件

worker.send(mes) //發(fā)送信息

他和spawn類(lèi)似都是通過(guò)返回的通道進(jìn)行通信。舉一個(gè)demo, 兩個(gè)文件master.js和worker.js 來(lái)看一下.

//master.js
const childProcess = require("child_process");
const worker = childProcess.fork("worker.js");

worker.on("message",function(mes){
    console.log(`from worder, message: ${mes}`);
});
worker.send("this is master");

//worker.js
process.on("message",function(mes){
    console.log(`from master, message: ${mes}`);
});
process.send("this is worker");

運(yùn)行，node app.js, 會(huì)輸出一下結(jié)果:

from master, message: this is master
from worker, message: this is worker

現(xiàn)在我們已經(jīng)學(xué)會(huì)了，如何使用child_process來(lái)創(chuàng)建一個(gè)基本的進(jìn)程了。
關(guān)于net 這一模塊，大家可以參考一下net模塊.

ok . 現(xiàn)在我們正式進(jìn)入，模擬nodeJS cluster模塊通信的procedure了。

這里先介紹一下，曾經(jīng)的cluster實(shí)現(xiàn)的一套機(jī)理。同樣，再放一次圖

我們使用net和child_process來(lái)模仿一下。

//master.js
const net = require("net");
const fork = require("child_process").fork;

var handle = net._createServerHandle("0.0.0.0", 3000);

for(var i=0;i<4;i++) {
   fork("./worker").send({}, handle);
}
//worker.js
const net = require("net");
//監(jiān)聽(tīng)master發(fā)送過(guò)來(lái)的信息
process.on("message", function(m, handle) {
  start(handle);
});

var buf = "hello nodejs"; ///返回信息
var res = ["HTTP/1.1 200 OK","content-length:"+buf.length].join("
")+"

"+buf;  //嵌套字

function start(server) {
    server.listen();
    var num=0;
    //監(jiān)聽(tīng)connection函數(shù)
    server.onconnection = function(err,handle) {
        num++;
        console.log(`worker[${process.pid}]:${num}`);
        var socket = new net.Socket({
            handle: handle
        });
        socket.readable = socket.writable = true;
        socket.end(res);
    }
}

ok~ 我們運(yùn)行一下程序, 首先運(yùn)行node master.js.
然后使用測(cè)試工具,siege.
siege -c 100 -r 2 http://localhost:3000
OK，我們看一下，到底此時(shí)的負(fù)載是否均衡。

worker[1182]:52
worker[1183]:42
worker[1184]:90
worker[1181]:16

發(fā)現(xiàn)，這樣任由worker去爭(zhēng)奪請(qǐng)求，效率真的很低呀。每一次，觸發(fā)請(qǐng)求，都有可能導(dǎo)致驚群事件的發(fā)生啊喂。所以，后來(lái)cluster改變了一種模式，使用master來(lái)控制請(qǐng)求的分配，官方給出的算法其實(shí)就是round-robin 輪轉(zhuǎn)方法。

現(xiàn)在具體的實(shí)現(xiàn)模型就變成這個(gè).

由master來(lái)控制請(qǐng)求的給予。通過(guò)監(jiān)聽(tīng)端口，創(chuàng)建一個(gè)socket，將獲得的請(qǐng)求傳遞給子進(jìn)程。
從tj大神那里借鑒的代碼demo:

//master
const net = require("net");
const fork = require("child_process").fork;

var workers = [];
for (var i = 0; i < 4; i++) {
   workers.push(fork("./worker"));
}

var handle = net._createServerHandle("0.0.0.0", 3000);
handle.listen();
//將監(jiān)聽(tīng)事件移到master中
handle.onconnection = function (err,handle) {
    var worker = workers.pop();  //取出一個(gè)pop
    worker.send({},handle);
    workers.unshift(worker);  //再放回取出的pop
}


//worker.js
const net = require("net");
process.on("message", function (m, handle) {
  start(handle);
});

var buf = "hello Node.js";
var res = ["HTTP/1.1 200 OK","content-length:"+buf.length].join("
")+"

"+buf;

function start(handle) {
    console.log("got a connection on worker, pid = %d", process.pid);
    var socket = new net.Socket({
        handle: handle
    });
    socket.readable = socket.writable = true;
    socket.end(res);
}

這里就經(jīng)由master來(lái)掌控全局了. 當(dāng)一個(gè)皇帝(worker)正在寵幸妃子的時(shí)候，master就會(huì)安排剩下的幾個(gè)皇帝排隊(duì)一個(gè)幾個(gè)的來(lái)。 其實(shí)中間的handle就會(huì)我們具體的業(yè)務(wù)邏輯. 如同:app.js.
ok~ 我們?cè)賮?lái)看一下cluster模塊實(shí)現(xiàn)多進(jìn)程的具體寫(xiě)法.

現(xiàn)在的cluster已經(jīng)可以說(shuō)完全做到的負(fù)載均衡。在cluster說(shuō)明我已經(jīng)做了闡述了。我們來(lái)看一下具體的實(shí)現(xiàn)吧

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模塊，當(dāng)然，完全也可以替換為socket模塊. 不過(guò)由于這樣書(shū)寫(xiě)，將集群和單邊給混淆了。 所以，推薦寫(xiě)法是將具體業(yè)務(wù)邏輯獨(dú)立出來(lái).

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就是開(kāi)啟具體的業(yè)務(wù)邏輯了

//app.js具體內(nèi)容
const net = require("net");
//自動(dòng)創(chuàng)建socket
const server = net.createServer(function(socket) { //"connection" listener
    socket.on("end", function() {
        console.log("server disconnected");
    });
    socket.on("data", function() {
        socket.end("hello
");
    });
});
//開(kāi)啟端口的監(jiān)聽(tīng)
server.listen(8124, function() { //"listening" listener
    console.log("working")
});

接著我們開(kāi)啟服務(wù)，node master.js
然后進(jìn)行測(cè)試
siege -c 100 -r 2 http://localhost:8124
我這里開(kāi)啟的是長(zhǎng)連接. 每個(gè)worker處理的長(zhǎng)連接數(shù)是有限的。所以，當(dāng)有額外的連接到來(lái)時(shí)，worker會(huì)斷開(kāi)當(dāng)前沒(méi)有響應(yīng)的連接，去處理新的連接。
不過(guò)，平常我們都是使用HTTP開(kāi)啟 短連接，快速處理大并發(fā)的請(qǐng)求。
這是我改成HTTP短連接之后的結(jié)果

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

那，怎么模擬大并發(fā)嘞？
e e e e e e e e e ...
自己解決啊~
開(kāi)玩笑的啦~ 不然我寫(xiě)blog是為了什么呢？ 就是為了傳播知識(shí).
在介紹工具之前，我想先說(shuō)幾個(gè)關(guān)于性能的基本概念
QPS(TPS),并發(fā)數(shù),響應(yīng)時(shí)間,吞吐量,吞吐率

自從我們和服務(wù)器扯上關(guān)系后,我們前端的性能測(cè)試真的很多。但這也是我們必須掌握的tip. 本來(lái)前端寶寶只需要看看控制臺(tái)，了解一下網(wǎng)頁(yè)運(yùn)行是否運(yùn)行順暢, 看看TimeLine，Profile 就可以了。 不過(guò)，作為一名有追求，有志于改變世界的童鞋來(lái)說(shuō)。。。
md~ 又要學(xué)了...
ok~ 好了，在進(jìn)入正題之前，我再放一次 線(xiàn)上的測(cè)試結(jié)果.

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

根據(jù)上面的數(shù)據(jù)，就可以得出，你網(wǎng)頁(yè)的大致性能了。
恩~ let"s begin

關(guān)于吞吐率有多種解讀，一種是:描繪web服務(wù)器單位時(shí)間處理請(qǐng)求的能力。根據(jù)這個(gè)描述,其單位就為: req/sec. 另一種是: 單位時(shí)間內(nèi)網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)量。 而根據(jù)這個(gè)描述的話(huà),他的單位就為: MB/sec.
而這個(gè)指標(biāo)就是上面數(shù)據(jù)中的Throughput. 當(dāng)然，肯定是越大越好了

這個(gè)和上面的吞吐率很有點(diǎn)關(guān)系的。 吞吐量是在沒(méi)有時(shí)間的限制下，你一次測(cè)試的傳輸數(shù)據(jù)總和。 所以，沒(méi)有時(shí)間條件的測(cè)試，都是耍流氓。
這個(gè)對(duì)應(yīng)于上面數(shù)據(jù)中的Data transferred.

熟悉數(shù)據(jù)庫(kù)操作的童鞋，應(yīng)該知道，在數(shù)據(jù)庫(kù)中常常會(huì)提到一個(gè)叫做事務(wù)的概念。 在數(shù)據(jù)庫(kù)中，一個(gè)事務(wù)，常常代表著一個(gè)具體的處理流程和結(jié)果. 比如，我現(xiàn)在想要的數(shù)據(jù)是 2013-2015年，數(shù)學(xué)期末考試成績(jī)排名. 這個(gè)就是一個(gè)具體的事務(wù)，那么我們映射到數(shù)據(jù)庫(kù)中就是，取出2013-2015年的排名，然后取平均值，返回最后的排序結(jié)果。 可以看出，事務(wù)并不單單指單一的操作，他是由一個(gè)或一個(gè)以上 操作組合而成具有 實(shí)際意義的。 那，反映到前端測(cè)試，我們應(yīng)該怎樣去定義呢？ 首先，我們需要了解，前端的網(wǎng)絡(luò)交流其實(shí)就是 請(qǐng)求-響應(yīng)模式. 也就是說(shuō)，每一次請(qǐng)求，我們都可以理解為一次事務(wù)(trans).
所以，TPS(transaction per second)就可以理解為1sec內(nèi)，系統(tǒng)能夠處理的請(qǐng)求數(shù)目.他的單位也就是: trans/sec . 你當(dāng)然也可以理解為seq/sec.
所以說(shuō)，TPS 應(yīng)該是衡量一個(gè)系統(tǒng)承載力最優(yōu)的一個(gè)標(biāo)識(shí).
TPS的計(jì)算公式很容易的出來(lái)就是: Transactions / Elapsed time.
不過(guò), 凡事無(wú)絕對(duì)。 大家以后遇到測(cè)試的時(shí)候，應(yīng)該就會(huì)知道的.

就是服務(wù)器能夠并發(fā)處理的連接數(shù)，具體我也母雞他的單位是什么。 官方給出的解釋是:

Concurrency is average number of simultaneous connections, a number which rises as server performance decreases.

這里我們就理解為，這就是一個(gè)衡量系統(tǒng)的承載力的一個(gè)標(biāo)準(zhǔn)吧。 當(dāng)Concurrency 越高，表示 系統(tǒng)承載的越多，但性能也越低。

ok~ 但是我們?nèi)绾卫眠@些數(shù)據(jù)，來(lái)確定我們的并發(fā)策略呢？ e e e e e e e ...
當(dāng)然， 一兩次測(cè)試的結(jié)果真的沒(méi)有什么卵用. 所以實(shí)際上，我們需要進(jìn)行多次測(cè)試，然后畫(huà)圖才行。 當(dāng)然，一些大公司，早就有一套完整的系統(tǒng)來(lái)計(jì)算你web服務(wù)器的瓶頸,以及 給出 最優(yōu)的并發(fā)策略.
廢話(huà)不多說(shuō)，我們來(lái)看看，如何分析，才能得出 比較好的 并發(fā)策略。

首先，我們這里的并發(fā)需要進(jìn)行區(qū)分. 一個(gè)是并發(fā)的請(qǐng)求數(shù)，一個(gè)是并發(fā)的用戶(hù)數(shù). 這兩個(gè)對(duì)于服務(wù)器是完全不同的需求。
假如100個(gè)用戶(hù)同時(shí)向服務(wù)器分別進(jìn)行10次請(qǐng)求，與1個(gè)用戶(hù)向服務(wù)器連續(xù)進(jìn)行1000次請(qǐng)求。兩個(gè)的效果一樣么？

一個(gè)用戶(hù)向服務(wù)器連續(xù)進(jìn)行1000次請(qǐng)求的過(guò)程中，任何時(shí)刻服務(wù)器的網(wǎng)卡接受緩存區(qū)中只有來(lái)自該用戶(hù)的1個(gè)請(qǐng)求，而100個(gè)用戶(hù)同時(shí)向服務(wù)器分別進(jìn)行10次請(qǐng)求的過(guò)程中，服務(wù)器網(wǎng)卡接收緩沖區(qū)中最多有100個(gè)等待處理的請(qǐng)求，顯然這時(shí)候服務(wù)器的壓力更大。

所以上面所說(shuō)的 并發(fā)用戶(hù)數(shù)和吞吐率 是完全不一樣的.
不過(guò)通常來(lái)說(shuō)，我們更看重的是Concurrency(并發(fā)用戶(hù)數(shù)). 因?yàn)檫@樣更能反映出系統(tǒng)的 能力。 一般，我們都會(huì)對(duì)并發(fā)用戶(hù)數(shù)進(jìn)行一些限制，比如apache的maxClients參數(shù).
ok~ 我們來(lái)實(shí)例分析一下吧.

首先，我們拿到一份測(cè)試數(shù)據(jù).

接著，我們進(jìn)行數(shù)據(jù)分析.
根據(jù)并發(fā)數(shù)和吞吐率的關(guān)系得出下列的圖.

OK~ 我們會(huì)發(fā)現(xiàn)從大約130并發(fā)數(shù)的地方開(kāi)始，吞吐率開(kāi)始下降，而且越多下降的越厲害。 主要是因?yàn)椋谇懊娌糠蛛S著用戶(hù)數(shù)的上升，空閑的系統(tǒng)資源得到充分的利用，當(dāng)然就和正太曲線(xiàn)一樣，總會(huì)有個(gè)頂點(diǎn)。 當(dāng)?shù)竭_(dá)一定值后，頂點(diǎn)就會(huì)出現(xiàn)了. 這就我們的系統(tǒng)的一個(gè)瓶頸.
接著，我們細(xì)化分析，響應(yīng)時(shí)間和并發(fā)用戶(hù)數(shù)的相關(guān)性

同樣額道理，當(dāng)并發(fā)數(shù)到達(dá)130左右，正對(duì)每個(gè)req的響應(yīng)時(shí)間開(kāi)始增加，越大越抖，這適合吞吐率是相關(guān)的。 所以，我們可以得出一個(gè)結(jié)論，該次連接 并發(fā)數(shù) 最好設(shè)置為100~150之間。 當(dāng)然，這樣的分析很膚淺，不過(guò)，對(duì)于我們這些前端寶寶來(lái)說(shuō)了解一下就足夠了。

接下來(lái),我們使用工具來(lái)武裝自己的頭腦.
這里主要介紹一個(gè)測(cè)試工具，siege.

事實(shí)上并發(fā)測(cè)試工具主要有3個(gè)siege,ab,還有webbench. 我這里之所以沒(méi)介紹webbench的原因，因?yàn)?，我在嘗試安裝他時(shí)，老子，電腦差點(diǎn)就掛了(我的MAC pro)... 不過(guò)后面，被聰明的我 巧妙的挽回~ 所以，如果有其他大神在MAC x11 上成功安裝，可以私信小弟。讓我學(xué)習(xí)學(xué)習(xí)。
ok~ 吐槽完了。我們正式說(shuō)一下siege吧

安裝siege利用MAC神器 homebrew, 就是就和js前端世界的npm一樣.
安裝ing:
brew install siege
安裝成功--bingo
接著，我們來(lái)看一下語(yǔ)法吧.

-c NUM 設(shè)置并發(fā)的用戶(hù)數(shù)量.eg: -c 100;

-r NUM 設(shè)置發(fā)送幾輪的請(qǐng)求，即，總的請(qǐng)求數(shù)為: -cNum*-rNum但是, -r不能和-t一起使用(為什么呢？你猜).eg: -r 20

-t NUM 測(cè)試持續(xù)時(shí)間，指你運(yùn)行一次測(cè)試需要的時(shí)間，在timeout后，結(jié)束測(cè)試.

-f file. 用來(lái)測(cè)試file里面的url路徑 eg: -f girls.txt.

-b . 就是詢(xún)問(wèn)開(kāi)不開(kāi)啟基準(zhǔn)測(cè)試(benchmark)。 這個(gè)參數(shù)不太重要，有興趣的同學(xué)，可以下去學(xué)習(xí)一下。

關(guān)于-c -r我就不介紹了。 大家有興趣，可以參考一下，我前一篇文章讓你升級(jí)的網(wǎng)絡(luò)知識(shí). 這里主要介紹一下 -f 參數(shù).
通常，如果我們想要測(cè)試多個(gè)頁(yè)面的話(huà)，可以新建一個(gè)文件，在文件中創(chuàng)建 你想測(cè)試的所有網(wǎng)頁(yè)地址.
比如:
//文件名為 urls.txt

www.example.com
www.example.org
123.45.67.89

然后運(yùn)行測(cè)試
siege -f your/file/path.txt -c 100 -t 10s
OK~ 關(guān)于進(jìn)程和測(cè)試的內(nèi)容就介紹到這了。

如果大家覺(jué)得，嘿, 這哥們寫(xiě)的文章不錯(cuò)呀~
能請(qǐng)我喝杯coffee，勉勵(lì)寫(xiě)出更優(yōu)質(zhì)的文章嗎？

轉(zhuǎn)載請(qǐng)注明出處和作者:https://segmentfault.com/a/1190000004621734