摘要：一般由客戶端發(fā)送，用來表示報文段中第一個數(shù)據(jù)字節(jié)在數(shù)據(jù)流中的序號，主要用來解決網(wǎng)絡(luò)包亂序的問題。為有效，為無效表示，當(dāng)數(shù)據(jù)包得到后，立馬給應(yīng)用程序使用到最頂端用來確保連接的安全。親，那進(jìn)程和線程區(qū)別是什么嘞這算是計算機(jī)的基本知識吧。

在正文之前，我想問大家一個問題:
問:親，你有基礎(chǔ)嗎？
答: 有啊，你說前端嗎？ 不就是HTML,JS,CSS 嗎? so easy~
問: oh-my-zsh... 好吧，那問題來了，挖掘機(jī)技術(shù)哪家強(qiáng)... 開玩笑。
現(xiàn)在才是問題的正內(nèi)容。

你知道TCP的基本內(nèi)容嗎？(母雞啊~)

好吧，那你知道TCP的3次握手，4次揮手嗎？(知道一點(diǎn)點(diǎn))

恩，好，那什么是進(jìn)程呢？什么是線程呢？(母雞啊。。)

那并發(fā)和并行又是什么呢？(母雞啊)

OMG, 那nodeJS多進(jìn)程實(shí)現(xiàn)你會嗎？（不會呀~~~ md ...這都是些shenmegui）

其實(shí)，說多了都是淚，這些都是程序員的基本素質(zhì)呀。。。 面tencent的時候，被一個總監(jiān)，罵的阿彌陀佛么么噠. 今天在這里和大家分享一下，我的血淚史。

工欲善其事,必先利其器

一個程序員境界的提升，并不在于你寫的一首好代碼，更在于你能說出代碼背后的故事。ok~ 雞湯灌完了。我們開始說方法了。
首先這幅圖大家必須記得非常清楚才行。

對了還有,
OSI七層模型大家應(yīng)該爛熟于心的。

其中TCP處理transport層，主要是用來建立可靠的連接。 而建立連接的基礎(chǔ)，是他豐富的報文內(nèi)容(md~超級多).我們先來解釋一下。 首先，我們TCP3次握手用的報文就是綠色的"TCP Flags"內(nèi)容。 通過發(fā)送ACK，SYN包實(shí)現(xiàn)。具體涉及的Tag詳見:

Source Port / Destination Port:這個就是客戶端口(源端口)和服務(wù)器端口（目的端口）. 端口就是用來區(qū)別主機(jī)中的不同進(jìn)程，通過結(jié)合源IP和目的IP結(jié)合，得出唯一的TCP連接。

Sequence Number(seqNumber): 一般由 客戶端發(fā)送，用來表示報文段中第一個數(shù)據(jù)字節(jié)在數(shù)據(jù)流中的序號，主要用來解決網(wǎng)絡(luò)包亂序的問題。

Acknowledgment Number(ACK): 即就是用來存放客戶端發(fā)來的seqNumber的下一個信號(seqNumber+1). 只有當(dāng) TCP flags中的ACK為1時才有效. 主要是用來解決不丟包的問題。

TCP flags: TCP中有6個首部，用來控制TCP連接的狀態(tài).取值為0,1.這6個有:URG，ACK，PSH，RST，SYN，F(xiàn)IN.

URG 當(dāng)為1時，用來保證TCP連接不被中斷, 并且將該次TCP內(nèi)容數(shù)據(jù)的緊急程度提升(就是告訴電腦，你丫趕快把這個給resolve了)

ACK 通常是服務(wù)器端返回的。 用來表示應(yīng)答是否有效。 1為有效，0為無效

PSH 表示，當(dāng)數(shù)據(jù)包得到后，立馬給應(yīng)用程序使用(PUSH到最頂端)

RST 用來確保TCP連接的安全。 該flag用來表示 一個連接復(fù)位的請求。 如果發(fā)生錯誤連接，則reset一次，重新連。當(dāng)然也可以用來拒絕非法數(shù)據(jù)包。

SYN 同步的意思,通常是由客戶端發(fā)送，用來建立連接的。第一次握手時: SYN:1 , ACK:0. 第二次握手時: SYN:1 ACK:1

FIN 用來表示是否結(jié)束該次TCP連接。 通常當(dāng)你的數(shù)據(jù)發(fā)送完后，會自動帶上FIN 然后斷開連接

恩，基本的TCP內(nèi)容，大家應(yīng)該掌握了吧。OK, go on.

還是一樣， 先上張圖，讓大家先看一下。 上面大家已經(jīng)基本了解了TCP里面相應(yīng)的字段，現(xiàn)在看看圖里面的是不是覺得有些親切嘞？

其實(shí)，大家看上面的圖，差不多都已經(jīng)能夠摸清楚，每次發(fā)送請求的內(nèi)容。其實(shí)，TCP3次握手是為了建立 穩(wěn)定可靠的連接。所以也就不存在神馬 2次連接等的怪癖。
(圖中flag說明:SYN包表示標(biāo)志位syn=1,ACK包表示標(biāo)志位ack=1,SYN+ACK包表示標(biāo)志位syn=1,ack=1)
現(xiàn)在，我們來正式進(jìn)入3次握手環(huán)節(jié)。

第一次握手. 客戶端向服務(wù)器發(fā)送一個SYN包，并且添加上seqNumber(假設(shè)為x),然后進(jìn)入SYN_SEND狀態(tài)，并且等待服務(wù)器的確認(rèn)。

第二次握手: 服務(wù)器接受SYN包，并且進(jìn)行確認(rèn)，如果該請求有效，則將TCP flags中的ACK 標(biāo)志位置1， 然后將AckNumber置為(seqNumber+1)，并且再添加上自己的seqNumber(y), 完成后，返回給客戶端.服務(wù)器進(jìn)入SYN_RECV狀態(tài).(這里服務(wù)端是發(fā)送SYN+ACK包)

第三次握手 客戶端接受ACK+SYN報文后，獲取到服務(wù)器發(fā)送seqNumber(y), 并且 將新頭部的AckNumber變?yōu)?y+1).然后發(fā)送給服務(wù)器，完成TCP3次連接。此時服務(wù)器和客戶端都進(jìn)入ESTABLISHED狀態(tài).

回答一下這個比較尷尬的問題，為什么只有3次握手，而不是4次，或者2次？
很簡單呀，因為3次就夠了,干嘛用4次。23333. 舉個例子吧，假如是2次的話， 可能會出現(xiàn)這樣一個情況。

當(dāng)客戶端發(fā)送一次請求A后，但是A在網(wǎng)絡(luò)延遲了很久， 接著客戶端又發(fā)送了一次B，但是此時A已經(jīng)無效了。 接著服務(wù)器相應(yīng)了B，并返回TCP連接頭，建立連接(這里就2次哈)。 然后，A 歷經(jīng)千山萬水終于到服務(wù)器了， 服務(wù)器一看有請求來了，則接受，由于一開始A帶著的TCP格式都是正確的，那么服務(wù)器，理所應(yīng)當(dāng)?shù)囊卜祷爻晒B接的flag，但是，此時客戶端已經(jīng)判斷該次請求無效，廢棄了。 然后服務(wù)器，就這么一直掛著(浪費(fèi)資源)，造成的一個問題是，md, 這個鍋是誰的？ 所以，為了保險起見，再補(bǔ)充一次連接就可以了。所以3次是最合適的。在Chinese中，以3為起稱為多，如果你用4，5，6，7，8...次的話，這不更浪費(fèi)嗎？

TCP4次揮手，是比較簡單的。大家對照上面那個圖，我們一步一步進(jìn)行一下講解。

第一次揮手: A機(jī)感覺此時如果keep-alive比較浪費(fèi)資源，則他提出了分手的請求。設(shè)置SeqNumber和AckNumber之后，向B機(jī)發(fā)送FIN包, 表示我這已經(jīng)沒有數(shù)據(jù)給你了。然后A機(jī)進(jìn)入FIN_WAIT_1狀態(tài)

第二次揮手:B機(jī)收到了A機(jī)的FIN包，已經(jīng)知道了A機(jī)沒有數(shù)據(jù)再發(fā)送了。此時B機(jī)會給A機(jī)發(fā)送一個ACK包，并且將AckNumber 變?yōu)?A機(jī)傳輸來的SeqNumber+1. 當(dāng)A機(jī)接受到之后，則變?yōu)镕IN_WAIT_2狀態(tài)。表示已經(jīng)得到B機(jī)的許可，可以進(jìn)行關(guān)閉操作。不過此時，B機(jī)還是可以向A機(jī)發(fā)送請求的。

第三次揮手 B機(jī)向A機(jī)發(fā)送FIN包，請求關(guān)閉，相當(dāng)于告訴A機(jī)，我這里也沒有你要的數(shù)據(jù)了。然后B機(jī)進(jìn)入CLOSE_WAIT狀態(tài).（這里還需要帶上SeqNumber，大家看圖說話就可以了）

第四次揮手 A機(jī)接收到B機(jī)的FIN包之后，然后同樣，發(fā)送一個ACK包給B機(jī)。 B機(jī)接受到之后，就斷開了。 而A機(jī) 會等待2MSL之后，如果沒有回復(fù)，確保服務(wù)器端確實(shí)是關(guān)閉了。然后A機(jī)也可以關(guān)閉連接。A,B都進(jìn)入了CLOSE狀態(tài).

明白了嗎？
大哥~ 等等，什么是2MSL呀~
哦，對哦。 這個還么說...
2MSL=2*MSL. 而MSL其實(shí)就是Maximum Segment Lifetime，中文意思就是報文最大生存時間。RFC 793中規(guī)定MSL為2分鐘，實(shí)際應(yīng)用中常用的是30秒，1分鐘和2分鐘等。 同樣上面的TIME_WAT狀態(tài)其實(shí)也就是2MSL狀態(tài)。 如果超過改時間，則會將該報文廢棄，然后直接進(jìn)入CLOSED狀態(tài).

親，請問php是一門什么語言? (提示，關(guān)于進(jìn)程)
官方回答: php是一門基于多線程的語言
親，請問nodeJS是一門什么語言？（提示，關(guān)于線程）
官方回答: Node.js是單線程!異步!非阻塞!(不過早已可以實(shí)現(xiàn)多進(jìn)程交互了)
那php和nodeJS區(qū)別在哪呢？具體可以見圖:
PHP

NodeJS

ok~ 簡單吧。
親，那進(jìn)程和線程區(qū)別是什么嘞？
go die /(ㄒoㄒ)/~~
這算是計算機(jī)的基本知識吧。 首先我們需要記住的是，進(jìn)程包括線程。這非常重要。

進(jìn)程就是系統(tǒng)分配資源的基本單位(比如CPU,內(nèi)存等)
線程就是程序執(zhí)行的最小單位

進(jìn)程有自己的空間，如果一個進(jìn)程崩潰不會引起其它進(jìn)程的崩潰。
線程，沒有自己獨(dú)立的空間，多個線程共享的是進(jìn)程的地址空間，當(dāng)然處理一些基本的如程序計數(shù)器,一組寄存器和棧等。
如果一個線程崩潰，它所在的進(jìn)程就崩潰了。 雖然說，多進(jìn)程很穩(wěn)定，但是進(jìn)程切換時，耗費(fèi)的資源也是很大的。 所以對于大并發(fā)的nodeJS來說，使用多線程的效果要遠(yuǎn)遠(yuǎn)比多進(jìn)程快，穩(wěn)定。

1.系統(tǒng)在啟動一個進(jìn)程的時候，會首先在資源中獨(dú)立一塊出來，在后臺建立一些列表進(jìn)行維護(hù)。 而，線程是比進(jìn)程低一個level的，所以創(chuàng)建線程所耗費(fèi)的資源要遠(yuǎn)遠(yuǎn)比，創(chuàng)建進(jìn)程的資源少。

由于進(jìn)程本身就比較復(fù)雜，所以如果進(jìn)行進(jìn)程切換的話，造成的性能損耗也是不言而喻的(因為多個進(jìn)程獨(dú)立，在切換的時候還需要保證各自的獨(dú)立性)。 而線程切換就不同了，因為在處在同一進(jìn)程下面，對于其他的進(jìn)程都是透明化的(內(nèi)存共享)，所以在進(jìn)行進(jìn)程切換時，所耗費(fèi)的資源遠(yuǎn)遠(yuǎn)比進(jìn)程切換的小。

在Linux和window下，CPU的分配是根據(jù)線程數(shù)來的，如果

總線程數(shù)<= CPU數(shù)量：并行運(yùn)行
總線程數(shù)> CPU數(shù)量：并發(fā)運(yùn)行

并行指的是，當(dāng)你的CPU核數(shù)比線程數(shù)多的話，則會將每個線程都分在一個CPU核里進(jìn)行處理。

并發(fā)指的是，當(dāng)你的CPU核數(shù)比線程數(shù)少的話，則會利用“時間片輪轉(zhuǎn)進(jìn)程調(diào)度算法”，對每個線程進(jìn)行同等的運(yùn)行。

4.細(xì)化進(jìn)程的處理，通常一個進(jìn)程可以拆分為多個線程進(jìn)行處理，就和模塊化處理是類似的，使用模塊化書寫的效果要遠(yuǎn)遠(yuǎn)比使用單main入口方式書寫 清晰，穩(wěn)定。

親， 并發(fā)和并行有什么共同點(diǎn)嗎？
恩~ 有的， 他們都有個‘并’子，字面上看起來都是同時執(zhí)行的意思。
沒錯，當(dāng)然只是字面上而已。
實(shí)際上，并發(fā)和并行是完全不同的概念。 這里主要和CPU核數(shù)有關(guān)。這里為了理解，拿線程來作為參考吧。
當(dāng)你的

總線程數(shù)<= CPU數(shù)量：并行運(yùn)行
總線程數(shù)> CPU數(shù)量：并發(fā)運(yùn)行

很明顯，并行其實(shí)是真正意義上的同時執(zhí)行。 當(dāng)線程數(shù)< CPU核數(shù)時，每個線程會獨(dú)立分配到一個CPU里進(jìn)行處理。
大家看過火影忍者嗎？
沒錯，就是鳴人 出關(guān) 口遁九尾之后。 他使用影分身，跑去各地支援同伴，對抗斑。 這里類比來說，就可以理解為， 每個CPU 都是鳴人的一個影分身，他們執(zhí)行這各自不同的工作，但是，在同一時間上，他們都在運(yùn)行。 這就是并行。
那并發(fā)嘞？
其實(shí)，并發(fā)有點(diǎn)難以理解，他做的工作其實(shí)，就是利用一系列算法實(shí)現(xiàn)，并行做的事。一個比較容易理解的就是“時間片輪轉(zhuǎn)進(jìn)程調(diào)度算法”。
即: 在系統(tǒng)控制下，每個線程輪流使用CPU，而且，每個線程使用時間必須很短(比如10ms), 所以這樣切換下來。我們(愚蠢的人類，哈哈哈), 天真的以為任務(wù)，真的是在"并行"執(zhí)行.

一開始nodeJS最令人詬病的就是他的單線程特性。既是絕招也是死穴，不過nodeJS發(fā)展很快，在v0.8版本就已經(jīng)添加了cluster作為內(nèi)置模塊，實(shí)現(xiàn)多核的利用。
關(guān)于nodeJS的進(jìn)程模塊，最主要的當(dāng)然還是cluster. 通過調(diào)用child_process.fork()函數(shù)來開啟進(jìn)程。 先看一個具體的demo(from 官網(wǎng))

var cluster = require("cluster");
var http = require("http");
var numCPUs = require("os").cpus().length;

if (cluster.isMaster) {
    console.log("master start...");

    // Fork workers.
    for (var i = 0; i < numCPUs; i++) {
        cluster.fork();
    }
    //用來監(jiān)聽子worker創(chuàng)建監(jiān)聽服務(wù)
    cluster.on("listening",function(worker,address){
        console.log("listening: worker " + worker.process.pid +", Address: "+address.address+":"+address.port);
    });

    cluster.on("exit", function(worker, code, signal) {
        console.log("worker " + worker.process.pid + " died");
    });
} else {
    http.createServer(function(req, res) {
        res.writeHead(200);
        res.end("hello world
");
    }).listen(0);
}

存放為app.js 然后運(yùn)行node app.js就可以實(shí)現(xiàn)一個簡單的多進(jìn)程效果。
結(jié)果可能為下:

master start...
listening: worker 1559, Address: null:57803
listening: worker 1556, Address: null:57803
listening: worker 1558, Address: null:57803
listening: worker 1557, Address: null:57803

可以從上面的demo中看出，通過cluster.isMaster來區(qū)分master和worker. 而master和worker之間使用listen(0)進(jìn)行通信.

server.listen(0):在master和worker通信過程，集群中的worker會打開一個隨機(jī)端口共用，通過socket通信像上例中的57803

當(dāng)然你也可以手動打開一個端口共享監(jiān)聽。像這樣.

 http.createServer(function(req, res) {
        res.writeHead(200);
        res.end("hello world
");
    }).listen(3000);

cluster對象的屬性和函數(shù)

cluster.setttings:配置集群參數(shù)對象

cluster.isMaster:判斷是不是master節(jié)點(diǎn)*

cluster.isWorker:判斷是不是worker節(jié)點(diǎn)*

Event: "fork": 監(jiān)聽創(chuàng)建worker進(jìn)程事件

Event: "online": 監(jiān)聽worker創(chuàng)建成功事件

Event: "listening": 監(jiān)聽worker開啟的http.listen

Event: "disconnect": 監(jiān)聽worker斷線事件

Event: "exit": 監(jiān)聽worker退出事件

Event: "setup": 監(jiān)聽setupMaster事件

cluster.setupMaster([settings]): 設(shè)置集群參數(shù)

cluster.fork([env]): 創(chuàng)建worker進(jìn)程

cluster.disconnect([callback]): 關(guān)閉worket進(jìn)程*

cluster.worker: 獲得當(dāng)前的worker對象*

cluster.workers: 獲得集群中所有存活的worker對象*

通過cluster.worker獲得的worker對象和相應(yīng)的參數(shù)

worker.id: 進(jìn)程ID號

worker.process: ChildProcess對象*

worker.suicide: 在disconnect()后，判斷worker是否自殺*

worker.send(message, [sendHandle]):* master給worker發(fā)送消息。注：worker給發(fā)master發(fā)送消息要用process.send(message)

worker.kill([signal="SIGTERM"]): 殺死指定的worker，別名destory()*

worker.disconnect(): 斷開worker連接，讓worker自殺

Event: "message": 監(jiān)聽master和worker的message事件

Event: "online": 監(jiān)聽指定的worker創(chuàng)建成功事件

Event: "listening": 監(jiān)聽master向worker狀態(tài)事件

Event: "disconnect": 監(jiān)聽worker斷線事件

Event: "exit": 監(jiān)聽worker退出事件

這些就是cluster的全部內(nèi)容。不過這僅僅只是內(nèi)容而已，如果使用cluster，這便是我們程序員要做的事了。

由于nodeJS 只能實(shí)現(xiàn)單進(jìn)程的效果，所以他的進(jìn)程數(shù)只能為一個，但是通過引用cluster模塊，可以開啟多個子進(jìn)程實(shí)現(xiàn)CPU的利用。
簡單進(jìn)程交互
運(yùn)行后的結(jié)果為:

[master] start master...
[master] fork: worker1
[master] fork: worker2
[master] fork: worker3
[master] fork: worker4
[master] online: worker1
[master] online: worker4
[master] online: worker2
[master] online: worker3
[worker] start worker ...1
[worker] start worker ...4
[worker] start worker ...2
[master] listening: worker4,pid:990, Address:null:3000
[master] listening: worker1,pid:987, Address:null:3000
[master] listening: worker2,pid:988, Address:null:3000
[worker] start worker ...3
[master] listening: worker3,pid:989, Address:null:3000

參照注釋代碼和上述的結(jié)果，我們可以很容易的得到一個觸發(fā)邏輯。
運(yùn)行過程是:

首先fork子進(jìn)程

觸發(fā)fork事件

創(chuàng)建成功，觸發(fā)online事件

然后重新執(zhí)行一遍app.js,通過isWorker判斷子進(jìn)程

創(chuàng)建子進(jìn)程服務(wù)->觸發(fā)master上的listening

st=>start: 首先fork子進(jìn)程
op1=>operation: 觸發(fā)fork事件
op2=>operation: 創(chuàng)建成功，觸發(fā)online事件
op3=>operation: 然后重新執(zhí)行一遍app.js,通過isWorker判斷子進(jìn)程
op4=>operation: 創(chuàng)建子進(jìn)程服務(wù)->觸發(fā)master上的listening
e=>end

st->op1->op2->op3->op4->e

上面只是創(chuàng)建滿負(fù)載子進(jìn)程的流程。 但怎樣實(shí)現(xiàn)進(jìn)程間的交互呢？ 很簡單，master和worker監(jiān)聽message事件，通過傳遞參數(shù)，進(jìn)行交互。

cluster.worker.send(message[,handleFn]) master向worker發(fā)送信息

process.send(message[,handleFn]); worker向master發(fā)送信息

這個是多進(jìn)程之間的通信
communication
我們來分解一下代碼塊:

//開啟master監(jiān)聽worker的通信
cluster.workers[id].on("message", function(msg){
          //...
        });
        
//開啟worker監(jiān)聽master的通信
process.on("message", function(msg) {
       //...
    });

運(yùn)行上面的demo. 這里就不細(xì)說，整個流程，只看一下信息通信這一塊了。

創(chuàng)建子進(jìn)程,觸發(fā)listening事件

使用process.on監(jiān)聽message

接受master發(fā)送過來的消息

再向master返回消息

st=>start: 創(chuàng)建子進(jìn)程,觸發(fā)listening事件
op1=>operation: 使用process.on監(jiān)聽message
op2=>operation: 接受master發(fā)送過來的消息
op3=>operation: 再向master返回消息
op4=>operation: others
e=>others

st->op1->op2->op3->op4

現(xiàn)在，nodeJS負(fù)載均衡應(yīng)該是最容易實(shí)現(xiàn)的，其內(nèi)部已經(jīng)幫我們封裝好了，我們直接調(diào)用就over了。
其中，實(shí)現(xiàn)負(fù)載均衡的模塊就是cluster。以前cluster確實(shí)很累贅。負(fù)載均衡的算法實(shí)現(xiàn)的不是很好，導(dǎo)致的下場就是npm2的興起。不過現(xiàn)在已經(jīng)實(shí)現(xiàn)了負(fù)載均衡，官方說法就是用round-robin,來進(jìn)行請求分配。 round-robin其實(shí)就是一個隊列的循環(huán)，灰常容易理解。先看一下，cluster封裝好實(shí)現(xiàn)的負(fù)載均衡.

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);
}

（哥哥，你騙人，這哪里實(shí)現(xiàn)了負(fù)載均衡，這不就是上面的算法么？)
是呀，，， 我又沒說負(fù)載均衡不是這個。
負(fù)載均衡就是幫你解決請求的分配問題。ok~ 為了證明，我沒有騙你，我們來進(jìn)行測試一下。
使用brew安裝siege測試,當(dāng)然你也可以使用其他測試工具，不過在MAC 上面最好使用siege和webbench或者ab，我這里使用siege

brew install siege

使用的測試語法就是

siege -c 并發(fā)數(shù) -t 運(yùn)行測試時間 URL

測試的時間后面需要帶上單位，比如s,m,h,d等。默認(rèn)單位是m(分鐘). 舉個例子吧.

siege -c 100 -t 10s http://girls.hustonline.net

對女生節(jié)網(wǎng)頁進(jìn)行 100次并發(fā)測試，持續(xù)時間是10s.
當(dāng)然siege里還有其他的參數(shù).

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

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

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

-f file. 用來測試file里面的url路徑.file的尾綴需要為.url. eg: -f girls.url.

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

siege常用的就是這幾個. 通常我們是搭配 -c + -r 或者-c + -t.
OK，現(xiàn)在我們開始我們的測試 procedure.
首先開啟多進(jìn)程N(yùn)odeJS. node app.js
使用siege -c 100 -t 10s 127.0.0.1:3000. (Ps: 當(dāng)然也可以使用http://localhost:3000進(jìn)行代替)
得到的結(jié)果為

Transactions:                 600 hits
Availability:              100.00 %
Elapsed time:                6.08 secs
Data transferred:            0.01 MB
Response time:                0.01 secs
Transaction rate:           98.68 trans/sec
Throughput:                0.00 MB/sec
Concurrency:                0.88
Successful transactions:         600
Failed transactions:               0
Longest transaction:            0.04
Shortest transaction:            0.00

在10s內(nèi)，發(fā)起了600次請求，最大的峰值是98.68 trans/sec。 通過統(tǒng)計分析，得到每個worker的分發(fā)量.

worker1:162
worker2:161
worker3:167
worker4:170

可以看出，基本上每個負(fù)載上分配的請求的數(shù)目都差不多。這就已經(jīng)達(dá)到了負(fù)載均衡的效果。
下一篇會對nodeJS已經(jīng)相關(guān)的測試工具做一些介紹哦。
盡請期待。
ending~

大家如果感興趣，給我一杯咖啡喝喝吧~

轉(zhuǎn)載請注明出處和作者
原文連接:https://segmentfault.com/a/1190000004569460