<source id="4vppl"><ins id="4vppl"></ins></source>
<u id="4vppl"><sub id="4vppl"><label id="4vppl"></label></sub></u>
<object id="4vppl"></object>
  • <u id="4vppl"><li id="4vppl"><label id="4vppl"></label></li></u>

    <object id="4vppl"></object>
    <b id="4vppl"><sub id="4vppl"><tr id="4vppl"></tr></sub></b>

      <i id="4vppl"><thead id="4vppl"></thead></i>

      <thead id="4vppl"><li id="4vppl"><label id="4vppl"></label></li></thead>

      當前位置:首頁 > 網站舊欄目 > 學習園地 > 設計軟件教程 > gen_server tasting 之超簡單名稱服務(再續)

      gen_server tasting 之超簡單名稱服務(再續)
      2010-01-13 23:15:27  作者:  來源:
         前幾天寫了篇《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 選項。用來取得服務滿負載情況下,執行容錯對吞吐量、響應時間及資源利用率性能指標的影響。

      環境配置

      network_env

       

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

       

      “服務器”主機配置

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

       

      pc_config

       

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

       

      測試執行

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

       

      taskmgr

       

      appmon_workload

       

      測試結果

      1. Complex 場景

       

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

      complex_tps_1

       

      complex_rt_1

       

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

       

      complex_tps_2

       

      complex_rt_2

       

      complex_cpu

       

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

       

      complex_mem

       

      2. Crash 場景

       

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

       

      crash_tps_pass_1

      Pass Transcation.

       

      crash_rt_1

       

      crash_tps_fail_1

      Fail Transcation.

       

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

       

      crash_tps_pass_2

      Pass Transcation.

       

      crash_rt_2

       

      crash_tps_fail_2

      Fail Transcation.

       

      crash_socket_10053

       

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

       

      crash_mem

       

      結果分析

                在 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 的支持很失望。

       

      Shell代碼 復制代碼
      1. sudo -i   
      2.   
      3. 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 映像。真的很強悍。


      安徽新華電腦學校專業職業規劃師為你提供更多幫助【在線咨詢
      国产午夜福三级在线播放_亚洲精品成a人片在线观看_亚洲自慰一区二区三区_久久棈精品久久久久久噜噜
      <source id="4vppl"><ins id="4vppl"></ins></source>
      <u id="4vppl"><sub id="4vppl"><label id="4vppl"></label></sub></u>
      <object id="4vppl"></object>
    1. <u id="4vppl"><li id="4vppl"><label id="4vppl"></label></li></u>

      <object id="4vppl"></object>
      <b id="4vppl"><sub id="4vppl"><tr id="4vppl"></tr></sub></b>

        <i id="4vppl"><thead id="4vppl"></thead></i>

        <thead id="4vppl"><li id="4vppl"><label id="4vppl"></label></li></thead>
        五月丁香综合缴情六月在线 | 性色国产福利在线 | 日本亚洲国产精品久久 | 亚洲美女天堂电影 | 亚洲欧美精品在线观看 | 一级国产精品一级国产精品片 |