熱門精品專業
測試用例設計
設計兩個場景，都配置 200 并發壓力：
- Complex： 通過 socket 混合調用 vsns 服務的 load_all、remove_all、remove、save、load 請求。無 Think time 迭代執行5分鐘。用來取得服務滿負載情況下吞吐量、響應時間及資源利用率性能指標。
- 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 種設計：
- 一旦服務失敗立即返回調用者，并給出異常描述（原因）。這種設計會將服務錯誤完全暴露，將重試（容錯）的機制依賴到客戶端。
- 服務失敗后一直等待服務就緒，什么時候正常了，什么時候重試。雖然容錯對客戶端透明了，但會引入延遲，對于實時的要求不好滿足。
- 對上邊第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 映像。真的很強悍。
安徽新華電腦學校專業職業規劃師為你提供更多幫助【在線咨詢】
