前幾天寫了篇《gen_server tasting 之超簡單名稱服務(wù)（續(xù)） 》東西，親身體驗了 erlang otp 的強悍威力。這周正好有時間對 vsns/erlang 做個性能測試，驗證傳說中的 erlang 強大威力，其中包括了容錯測試用例，關(guān)注在大并發(fā)壓力下（13000tps）時，服務(wù) oops 后通過 supervisor restart 時對整體性能的影響。在最后還包括了一些對服務(wù)容錯設(shè)計上的一些思考。

 

測試用例設(shè)計

設(shè)計兩個場景，都配置 200 并發(fā)壓力：

 

1. Complex： 通過 socket 混合調(diào)用 vsns 服務(wù)的 load_all、remove_all、remove、save、load 請求。無 Think time 迭代執(zhí)行5分鐘。用來取得服務(wù)滿負載情況下吞吐量、響應(yīng)時間及資源利用率性能指標。
2. Crash： 在執(zhí)行 Complex 場景過程中通過 kernel_oops 調(diào)用來 crash 名稱服務(wù)。啟用“continue on error” LoadRunner run-time 選項。用來取得服務(wù)滿負載情況下，執(zhí)行容錯對吞吐量、響應(yīng)時間及資源利用率性能指標的影響。

環(huán)境配置

 

          環(huán)境是很簡單的，精力有限，呵呵。需要說明的是，由于手上只有 Global 100 的 LoadRunner License，所以計劃的 200 并發(fā)平均分配到兩個測試機上，而且是啟的獨立 Controller，因此下邊的吞吐量和響應(yīng)時間結(jié)果也只能分別給出了。

 

“服務(wù)器”主機配置

          說是服務(wù)器，實際是我的辦公機器，HP 商用機。手頭機器有限，呵呵。倒不是沒有其他資源，只是考慮本次測試很原始，純屬個人娛樂，而且自己的機器調(diào)調(diào)配配、修修改改不麻煩。

 

 

          測試機這里就不例了，兩臺也是 HP 商用機，不過配置很好 Intel Core 2 Duo 2.8GHz，2G 內(nèi)存，呵呵夠用。

 

測試執(zhí)行

執(zhí)行的力工細節(jié)就不說了，總之是負載很大，服務(wù)器飽和，有圖為證。

 

 

 

測試結(jié)果

1. Complex 場景

 

測試機 A 的吞吐量和響應(yīng)時間曲線。

 

 

測試機 B 的吞吐量和響應(yīng)時間曲線。

 

 

 

 

          注：其中的 “Wait%” 指標是無效的，nmon （nmon_x86_debian31(11f) 版本）采集的結(jié)果都是 0。我認為這是個 Bug，再不就是 debian 31 和 ubuntu 8.10 差異造成的。已經(jīng)將該問題提交到 IBM developerWorks 的 AIX and UNIX Performance Tools Forum，不過沒人回答 ：（。難不成 je 的哪位大蝦能給個意見？

 

 

2. Crash 場景

 

測試機 A 的吞吐量和響應(yīng)時間曲線。

 

Pass Transcation.

 

 

Fail Transcation.

 

測試機 B 的吞吐量和響應(yīng)時間曲線。

 

Pass Transcation.

 

 

Fail Transcation.

 

 

注：其中的 “Error: reset_conn once.” 是測試腳本中通過 lr_error_message 函數(shù)人為寫入的，調(diào)試用。

 

 

結(jié)果分析

          在 Complex 測試場景中，可以看到 vsns 服務(wù)在滿負載情況下吞吐量能夠持續(xù)、穩(wěn)定的達到 13000tps（兩臺測試機總合），響應(yīng)時間也穩(wěn)定保持在 0.015 秒上下。在服務(wù)器資源方面，很明顯 CPU 和內(nèi)存已經(jīng)飽和，也是因為我這個臨時的“服務(wù)器”總共才 512M 物理內(nèi)存，還沒測試機一半強（2G），不過這也恰恰說明 erlang 面對艱巨條件時還是很堅挺的，呵呵。等回頭和同事商量給我這臺充當服務(wù)器的辦公機器加條內(nèi)存，估計那樣一定會提高不少。當然這和測試中對 vsns 提交存儲的 key/value 大小有直接關(guān)系。

          可能對于 Crash 測試場景更有意義，現(xiàn)在就來一起看看。CPU 和內(nèi)存也與上面一樣，大負載下全都飽和。吞吐量和響應(yīng)時間也和 Complex 測試一致。在整個 3 分鐘的測試場景中，Crash 的 kernel_oops 方法是在 1 分 30 秒時提交的，通過響應(yīng)時間可以明顯看到其中的變化，響應(yīng)“加快”的原因在于 Socket 連接被服務(wù)器斷開造成的（此時調(diào)用都很快失敗）。saleyn_tcp_serverk 中的 client 通信進程由于 name_server 進程 crash 而調(diào)用失敗后紛紛退出，造成綁定在該進程上的 socket 全部失效而強制關(guān)閉。在這樣的大的吞吐量下，共造成了 99 個事務(wù)報 Connection Abort（10053）異常。隨后 erlang 監(jiān)控進程將 name_server 進程啟動，服務(wù)恢復正常。但從測試結(jié)果來看，兩臺測試機都有 10 秒左右的受影響時期，通過觀察發(fā)現(xiàn)其間不是全部 vsns 服務(wù)調(diào)用都失敗，而是部分正常部分失敗。通過失敗調(diào)用的吞吐量曲線可以看到，在 13000tps 壓力下 erlang 進程 crash 后，在容錯重新啟動過程中，對于 client 來講每秒會有50個左右的調(diào)用請求失敗。同時在給出的可用物理內(nèi)存曲線中可以看到，進程 crash 后有明顯的 5M 內(nèi)存釋放發(fā)生，當然這包括 name_server 保存的進程字典數(shù)據(jù)。個人認為上面這些可以說明，erlang 進程的監(jiān)控樹結(jié)構(gòu)是可以有效達到容錯目的，但在大負載情況下，服務(wù)的 crash 對吞吐量影響還是不小的，起碼性能下降不會很快緩解，當然這會考慮負載輕重。總體還講還可以，尤其還是在這么爛的臺式機上，呵呵。

 

對服務(wù)容錯設(shè)計的思考

          在進行上面所說的這個 Crash 場景測試時，在考慮是否應(yīng)該將服務(wù)異常或不可用的信息暴露給客戶端應(yīng)用（服務(wù)消費者）呢？尤其是服務(wù)間存在互相委托關(guān)系時，比如開發(fā) Service Hub 服務(wù)聚合或是 Service 擴展服務(wù)時。我想這可以有 3 種設(shè)計：

 

1. 一旦服務(wù)失敗立即返回調(diào)用者，并給出異常描述（原因）。這種設(shè)計會將服務(wù)錯誤完全暴露，將重試（容錯）的機制依賴到客戶端。
2. 服務(wù)失敗后一直等待服務(wù)就緒，什么時候正常了，什么時候重試。雖然容錯對客戶端透明了，但會引入延遲，對于實時的要求不好滿足。
3. 對上邊第2點的補充，即服務(wù)重試次數(shù)和等待時間進行限定/可配置。就像erlang otp的supervisor設(shè)計相似。

          很明顯，第 3 種方式應(yīng)該最有優(yōu)勢，兼顧了服務(wù)性能和容錯處理，當然實現(xiàn)起來可以也最復雜了。

 

用到的幾個優(yōu)化方法

1. 啟用 linux kernel epoll
configure --enable-kernel-poll
erl +K true parameter

2. 擴大 linux nproc 和 nofile limits
* soft nproc 2407
* hard nproc 16384
* soft nofile 1024
* hard nofile 65536

3. 擴大 linux 和 erlang 端口
echo 1024 65535 > ip_local_port_range
set ERL_MAX_PORTS = 102400

4. 啟用 erlang SMP
erl -smp enable +S 2

5. 擴大進程數(shù)量
erl +P 102400

6. 擴大 linux tcp 協(xié)議棧中讀寫緩沖區(qū)大小，將影響 tcp window 大小
echo "640000" > /proc/sys/net/core/rmem_default
echo "640000" > /proc/sys/net/core/rmem_max
echo "640000" > /proc/sys/net/core/wmem_default
echo "640000" > /proc/sys/net/core/wmem_max

 

          本文涉及的內(nèi)容只涉及基礎(chǔ)性的驗證、測試，未涉及具體的 erlang 軟件，且待我深入研究。Erlang rising~

 

          附件 vsns_perf.zip 為備份目的所添加，請勿下載使用。

 

// 2009.02.16 16:29 添加 ////

 

          關(guān)于 nmon 未能在 ubuntu 8.10 上獲得 cpu wio% 指標的問題，想到有可能是未以 root 權(quán)限啟動 nmon 進程的原因，不過能過剛才驗證，結(jié)果還不是一樣，不理想。盡管 vmstat 取得/確認了系統(tǒng)已經(jīng)出現(xiàn) wait io，但 nmon 的 wio% 采集結(jié)果還始終是 0。nmon_x86_debian31(11f) 版本對 ubuntu 8.10 的支持很失望。

 

sudo -i

nmon -c310 -s1 -r -f

 

// 2009.02.17 17:04 添加 ////

 

          呵呵，說是遲那是快。上面說的 nmon （nmon_x86_debian31(11f) 版本）采集的“Wait%” 結(jié)果都是 0 的問題，nagger 已經(jīng)確認 ，并已提供新的 nmon_x86_12a 版本下載 ，包括了最新的 Ubuntu 8.10 系統(tǒng)的 nmon 映像。真的很強悍。

安徽新華電腦學校專業(yè)職業(yè)規(guī)劃師為你提供更多幫助【在線咨詢】