ESFramework底層使用最高效的IOCP（IO完成端口）模型，使得數(shù)據(jù)收發(fā)與處理達(dá)到最高性能。另外，ESFramework只會(huì)在需要時(shí)才使用必要的資源（如CPU、內(nèi)存），并且會(huì)及時(shí)釋放持有的資源，可以超長時(shí)間（比如數(shù)年）穩(wěn)定運(yùn)行，絕不會(huì)有內(nèi)存泄露、死線程堆積等情況發(fā)生。由于ESFramework和StriveEngine使用的是同樣的底層內(nèi)核，所以本測(cè)試的結(jié)果對(duì)StriveEngine也是適用的。
本實(shí)驗(yàn)用于測(cè)試ESFramework/StriveEngine服務(wù)端引擎內(nèi)核的性能和穩(wěn)定性，測(cè)試程序使用最新發(fā)布的ESFramework 4.2版本。
一．準(zhǔn)備工作測(cè)試的機(jī)器總共有3臺(tái)，都是普通的PC，一臺(tái)作為服務(wù)器，兩臺(tái)作為客戶端。
作為服務(wù)器是PC配置如下：
操作系統(tǒng)：Windows Server 2003 Enterprise Edition SP2
CPU：Pentium Dual-Core CPU E5400 @ 2.70GHz
內(nèi)存：2G
二．測(cè)試策略本實(shí)驗(yàn)所采用的策略是這樣的：
（1）每個(gè)客戶端實(shí)例首先與服務(wù)器建立N個(gè)TCP連接，然后依次在每個(gè)TCP連接上發(fā)送一個(gè)36字節(jié)的消息。遍歷一次完畢后，等待（Sleep）M毫秒，再進(jìn)行下一輪遍歷發(fā)送。
（2）服務(wù)端接收到消息后，解析消息，然后累加消息的個(gè)數(shù)。
（3）客戶端統(tǒng)計(jì)已發(fā)消息的總數(shù)，并計(jì)算上一秒發(fā)送的請(qǐng)求數(shù)。
（4）服務(wù)端統(tǒng)計(jì)已接收消息的總數(shù)，并計(jì)算上一秒接收的請(qǐng)求數(shù)。
三．測(cè)試過程1．測(cè)試方案一：連接總數(shù)3000，每輪發(fā)送間隔100ms
（1）在作為服務(wù)器的PC上啟動(dòng)服務(wù)端。
（2）在作為客戶端的兩臺(tái)PC上分別運(yùn)行一個(gè)客戶端實(shí)例。每個(gè)客戶端實(shí)例設(shè)定連接數(shù)1500，每輪發(fā)送的間隔為100。
（3）如此，服務(wù)端的總的連接數(shù)為3000，以下是運(yùn)行一段時(shí)間后的截圖：
在該測(cè)試過程中，服務(wù)端的每秒處理的消息數(shù)量在26000 ~30000之間波動(dòng)，而CPU持續(xù)在80%以上。
另外，在客戶端的PC上通過NetLimitter可以看到每個(gè)連接上發(fā)出的數(shù)據(jù)流量：
2．測(cè)試方案二：連接總數(shù)6000，每輪發(fā)送間隔300ms
將方案一啟動(dòng)的各程序全部關(guān)掉，重頭再來一次。
（1）在作為服務(wù)器的PC上啟動(dòng)服務(wù)端。
（2）在作為客戶端的兩臺(tái)PC上分別運(yùn)行一個(gè)客戶端實(shí)例。每個(gè)客戶端實(shí)例設(shè)定連接數(shù)3000，每輪發(fā)送的間隔為400。
（3）如此，服務(wù)端的總的連接數(shù)為6000，以下是運(yùn)行一段時(shí)間后的截圖：
在該測(cè)試過程中，服務(wù)端的每秒處理的消息數(shù)量在14000 ~18000之間波動(dòng)，而CPU持續(xù)在65%以上。
3．測(cè)試方案三：我們最后測(cè)試一種極端的情況，那就是極少的連接數(shù)，極小的發(fā)送間隔。連接總數(shù)十多個(gè)，每輪發(fā)送間隔0ms。
（1）在作為服務(wù)器的PC上啟動(dòng)服務(wù)端。
（2）在作為客戶端的一臺(tái)PC上逐個(gè)啟動(dòng)客戶端，每個(gè)客戶端設(shè)定連接數(shù)為1，發(fā)送間隔為0ms，這樣，當(dāng)增加到12個(gè)時(shí)，服務(wù)端的CPU幾乎始終維持在90%以上。
運(yùn)行一段時(shí)間后的截圖如下所示：
在該測(cè)試過程中，服務(wù)端的每秒處理的消息數(shù)量在70000 ~ 80000之間波動(dòng)，而CPU持續(xù)在90%以上。 【方案三測(cè)試 于2012.04.01所新增】
四．測(cè)試結(jié)論第三種方案是比較極端的，在現(xiàn)實(shí)場(chǎng)景中很少碰到，但是作為一個(gè)極端的測(cè)試還是有必要的。一般服務(wù)器都要承載至少數(shù)千用戶同時(shí)在線，所以我們主要討論大連接數(shù)的測(cè)試方案。
對(duì)于大連接數(shù)測(cè)試，除了前兩種方案的測(cè)試以外，我們還進(jìn)行了其它方案的測(cè)試，比如設(shè)置更小的連接數(shù)（至少1000）和更小的發(fā)送間隔（至少5ms），或設(shè)置更大的連接數(shù)和更大的發(fā)送間隔。測(cè)試反映，這臺(tái)作為服務(wù)器的PC能承載的最佳并發(fā)連接數(shù)在4000左右，此時(shí)，服務(wù)器的吞吐量可以達(dá)到最大（每秒處理30000個(gè)左右的消息）。當(dāng)連接數(shù)進(jìn)一步增加時(shí)，吞吐量會(huì)降下來。最佳并發(fā)連接數(shù)和最大吞吐量的值與服務(wù)器機(jī)器的配置密切相關(guān)。
五．測(cè)試程序本文末會(huì)提供測(cè)試程序的壓縮包下載。在壓縮包內(nèi)附帶了測(cè)試的服務(wù)端和客戶端程序，有興趣的朋友可以在自己的服務(wù)器上做更多的策略測(cè)試。在自己運(yùn)行測(cè)試時(shí)，要注意以下幾點(diǎn)：
（1）服務(wù)端最好運(yùn)行在一臺(tái)單獨(dú)的機(jī)器上。如果客戶端也運(yùn)行在服務(wù)端所在的機(jī)器上，則會(huì)嚴(yán)重地影響服務(wù)端的吞吐量。
（2）合理地設(shè)置客戶端的連接數(shù)和發(fā)送時(shí)間間隔。
（3）客戶端運(yùn)行的機(jī)器的操作系統(tǒng)對(duì)tcp連接數(shù)可能有最大值限制（有的是三千多），如果遇到這種系統(tǒng)，而單個(gè)客戶端實(shí)例的連接數(shù)的設(shè)定又大于這個(gè)限制值，則會(huì)導(dǎo)致后續(xù)的tcp連接失敗。若發(fā)生這種情況，請(qǐng)關(guān)閉客戶端并重啟，然后設(shè)定較小的連接數(shù)，再次測(cè)試�？梢远嚅_幾個(gè)客戶端實(shí)例，來增加連接數(shù)。
（4）如果服務(wù)器上有防火墻軟件，可能會(huì)影響測(cè)試結(jié)果，最好關(guān)閉服務(wù)器上的防火墻進(jìn)行測(cè)試。
（5）如果是在Internet上測(cè)試，請(qǐng)確保服務(wù)端帶寬和客戶端的帶寬都足夠大。
