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

 

測試用例設計

設計兩個場景，都配置 200 并發壓力：

 

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

環境配置

 

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

 

“服務器”主機配置

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

 

 

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

 

測試執行

執行的力工細節就不說了，總之是負載很大，服務器飽和，有圖為證。

 

 

 

測試結果

1. Complex 場景

 

測試機 A 的吞吐量和響應時間曲線。

 

 

測試機 B 的吞吐量和響應時間曲線。

 

 

 

 

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

 

 

2. Crash 場景

 

測試機 A 的吞吐量和響應時間曲線。

 

Pass Transcation.

 

 

Fail Transcation.

 

測試機 B 的吞吐量和響應時間曲線。

 

Pass Transcation.

 

 

Fail Transcation.

 

 

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

 

 

結果分析

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

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

 

對服務容錯設計的思考

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

 

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

          很明顯，第 3 種方式應該最有優勢，兼顧了服務性能和容錯處理，當然實現起來可以也最復雜了。

 

用到的幾個優化方法

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. 擴大進程數量
erl +P 102400

6. 擴大 linux tcp 協議棧中讀寫緩沖區大小，將影響 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

 

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

 

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

 

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

 

          關于 nmon 未能在 ubuntu 8.10 上獲得 cpu wio% 指標的問題，想到有可能是未以 root 權限啟動 nmon 進程的原因，不過能過剛才驗證，結果還不是一樣，不理想。盡管 vmstat 取得/確認了系統已經出現 wait io，但 nmon 的 wio% 采集結果還始終是 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%” 結果都是 0 的問題，nagger 已經確認 ，并已提供新的 nmon_x86_12a 版本下載 ，包括了最新的 Ubuntu 8.10 系統的 nmon 映像。真的很強悍。

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