效能測試-如何測一個入口網站是否支援10萬用戶同時線上
阿新 • • 發佈：2019-02-13
這個帖子的內容比較典型，大家有興趣可以也思考一下。帖子源於51testing論壇
先是樓主提出問題：
最近公司一個專案,是個入口網站,需要做效能測試,根據專案特點定出了主要測試項和測試方案
一種是測試幾個常用頁面能接受的最大併發數(使用者名稱引數化,設定集合點策略)
一種是測試伺服器長時間壓力下,使用者能否正常操作(使用者名稱引數化,迭代執行指令碼)
還有一種則需要測試伺服器能否接受10萬用戶同時線上操作,但使用的Loadrunner的license只能支援1萬用戶,請問這時該如何制定該方案?
後面跟著大家的回覆：
網友 xingcyx 的回覆：
1、找10臺電腦也沒用，license仍然只支援10000個。
2、找HP支援。當然，前提是你有足夠的錢。
3、測到10000使用者併發。我認為，通常情況下10000使用者併發，支援100000使用者線上，沒有問題的。
網友 jackloo 的回覆：
總的來說這一類的效能指標對大多數軟體來說沒什麼實際意義，更多的是對硬體的要求。
如果是用IIS做應用伺服器的話，單臺可承受的最大併發數不可能達到10萬級，那就必須要使用叢集，通過多臺機器做負載均衡來實現；
如果是用websphere之類的應用伺服器的話，單臺可承受的最大併發數可以達到10萬級，但為效能考慮還是必須要使用叢集，通過多臺機器做負載均衡來實現；
那麼，你只要叢集的伺服器足夠多，10萬併發數當然可以達到了。
通常有1個簡單的計算方式，1個連線產生1個session，每個session在伺服器上有個記憶體空間大小的設定，在NT上是3M，那麼10萬併發就需要300G記憶體，當然實際使用中考慮其他程式也佔用記憶體，所以準備的記憶體數量要求比這個還要多一些。
還有10萬個使用者同時線上，跟10萬個併發數是完全不同的2個概念。這個樓上已經說了。但如何做這個轉換將10萬個同時線上使用者轉換成多少個併發數呢？
這就必須要有大量的歷史日誌資訊來支撐了。系統日誌需要有同時線上使用者數量的日誌資訊，還需要有使用者操作次數的日誌資訊，這2個數據的比例就是你同時線上使用者轉換到併發數的比例。
另外根據經驗統計，對於1個JAVA開發的WEB系統（別的我沒統計過，給不出資料），一般1臺雙CPU、2G記憶體的伺服器上可支援的最大併發數不超過 500個（這個狀態下大部分操作都是超時報錯而且伺服器很容易宕機，其實沒什麼實際意義），可正常使用（單步非大資料量操作等待時間不超過20秒）的最大併發數不超過300個。
假設你的10萬同時線上使用者轉換的併發數是9000個，那麼你最少需要這樣的機器18臺，建議不少於30臺。
當然，你要是買個大型伺服器，裡面裝有200個CPU、256G的記憶體，千兆光纖頻寬，就算是10萬個併發使用者，那速度，也絕對是嗖嗖的。
樓主的回覆：
謝謝jackloo !
再請問如果我想測試10000個使用者同時線上做常用操作的話(每兩秒加一個使用者,一直加到10000),對伺服器的要求有多高?
網友 jackloo 的回覆：
套用1句經典臺詞“高，實在是高”
呵呵。另外暴寒1下，你的設定光全部進入執行狀態就需要接近6個小時。
具體的你可以拿1個系統來壓一下看看，可能會出現以下情況：
1。伺服器宕機；
2。客戶端宕機；
3。從某個時間開始伺服器拒絕請求，客戶端上顯示的全是錯誤；
4。勉強測試完成，但網路堵塞或測試結果顯示時間非常長。假設客戶端和伺服器之間百兆頻寬，百兆/10000=10K，那每個使用者只能得到10K，這個速度接近1個64K的MODEM上網的速度；
另外以上分析全都沒考慮系統的後臺，比如資料庫、中介軟體等。
我從沒遇到你說的這樣的效能需求過，也只好憑感覺隨便掰掰：
1。伺服器方面：上面說的那樣的PC SERVER需要50臺；
2。網路方面：按每個使用者50K，那至少5根百兆頻寬獨享，估計僅僅網路延遲就大概是秒一級的；
3。如果有資料庫，至少是ORACLE，最好是SYSBASE，SQL SERVER是肯定頂不住的。資料庫伺服器至少需要10臺4CPU、16G記憶體的機器；
4。如果有CORBA，那至少再準備10臺4CPU、16G記憶體的機器；
再加上負載均衡、防火牆、路由器和各種軟體等，總之沒個1000萬的資金投入，肯定搞不定。
網友 mybasswood 的回覆：
如果是10萬用戶的話要看做些什麼哈.
比如對於voip來說,假設有10萬用戶的話,伺服器規定每個client至少要在3600秒內到伺服器成功報到一次,否則就被伺服器cancel掉.
client是每隔60秒註冊一次.
所以就要推算在3600秒內,每一個client至少成功報到一次是最少的標準.要10萬用戶在3600秒內被伺服器吃掉才可以---這是最低要求.
最高要求是: 在60秒內所有的10萬用戶去註冊,如果伺服器在60秒可以都吃掉的話,每秒種的平均併發差不多是3334.
最低要求是:在3600秒內所有的10使用者去註冊,如果伺服器在3600秒內都可以吃掉的話,每秒鐘的平均併發使用者差不多是60個.還有一過問題是客戶端要在3600秒內傳送至少60次,至少有一次成功.再加上這些使用者分佈在全球各地的話,這樣數值應該還會有變化的.
下面是偶的看法：
給樓主一個建議吧。
你在公司中的測試環境是一定的，你需要做得是現在這個環境中確認一下系統在當前環境下的實際處理能力。如果還有資源，再做一下可伸縮性的測試。
然後對測試結果進行分析，對系統的處理能力和可伸縮性做一個描述。
當然，要在報告中說明你的測試環境。
另外一位網友robust 的留言：
你的意思是否想用10000個使用者測試結果來推測一下10萬個使用者?
還是如有些老兄說的,測試一下什麼伸縮性測試.然後也來個報告,無非也是想用1萬個來推測10萬個的情況?(評註:那樣的話要你做什麼效能測試,只要計算一下就可以得效能結果了.)
還是如有些老兄說的,這一類的效能指標對大多數軟體來說沒什麼實際意義，更多的是對硬體的要求?(評註:那樣的話要你做什麼效能測試,做什麼效能調優,只要計算一下,新增硬體就可以了.)
實際上,"實踐是檢驗真理的唯一標準!"這句話才是硬道理.只有真實地測試過才知道.任何推測只是推測,並不能反映真實的情況.
至於效能測試工具,LR只是普及率高(市場佔有率高),並不是在效能指標上有優勢.世界上比它厲害的工具有不少,舉個例子siprent通訊公司的avalanche2500,大型計算機實驗室配備的效能測試工具.支援錄製/回放,測試結果分析等.它可以模擬從資料層到應用層的協議,(當然也包含http-web),單個支援100萬併發連線.拿它也可以測試100萬級的併發效能.
又是偶的回覆：
樓上的提到的見解不錯，不過對效能測試的理解有些偏差。
先拋開效能測試工具不談，其實這個問題是討論到一個性能測試到底該怎麼做。
簡單舉個例子，如果你想知道一種新的疫苗對人的作用，是不是要把所有的地球人全部找來每個人打一針試試呢？當然不是，只能是通過試驗和抽樣，然後通過統計學的方法來計算出一個模型，通過樣本的表現來估算總體的特徵。這就是統計學研究的領域，。不過請注意，統計學所包含的內容並不是像樓上的老兄所說的一樣：只要計算一下就可以得效能結果了。
效能測試也同樣如此。
樓主提到的效能需求應該是系統上線以後可能要面臨的壓力，先不討論這個需求是否準確和有效，我們先假定它是有效的。那麼，既然要驗證的是系統在上線以後是否有能力應對10萬用戶同時線上的情況，那麼自然要用生產環境來測試。如果有，那麼 OK，可以作這個測試。至於工具，其實可以由開發人員幫忙寫一些簡單的指令碼負責加壓，再通過其他第三方工具收集測試資料就是了。
但是如果沒有生產環境，只有一臺雙CPU，3G記憶體的 2850 伺服器，怎麼辦？這就好像上面提到的例子。可行的方法是在這臺伺服器上使用不同級別的負載來進行測試，並根據測試資料獲得系統在這種環境下的最佳負載和最大負載，並根據測試資料對負載和資源消耗的情況進行估算，找到它們之間的關係。
一般來說，大型的入口網站不會只用一臺超級超級的伺服器來承擔所有的負載，因為採用負載均衡和叢集技術可以更好的解決這個問題，一定是多臺伺服器分佈在不同的地方，內容通過內容分發網路同步到各臺伺服器上。使用者在訪問時，其實是被應用層或者前端裝置路由到一個合適的伺服器去的。所以在測試時，對於可伸縮性的測試是必需的，一定要了解到 cluster 數量增加時，系統的響應能力是否可以線性的增加，也就是說是否可以承受更大的壓力，為更多的使用者提供服務。
最後總結一下，對於效能測試，要作的是確認系統的響應能力，然後看系統是否可以滿足效能需求。
如果大家有不同的見解，歡迎 PK 討論
繼續偶的回覆：
to jackloo
你所提到的對於硬體資源和軟體資源的要求並不完全準確。因為實際的資源消耗要根據網站所提供的業務型別來推算。
對於大多數入口網站來說，可供訪問的大多是靜態頁面。在使用者訪問時，系統只是返回一個靜態頁面給使用者，並不需要保持 session，而且這種情況下負載主要集中在I/O和網路流量方面——這也是為什麼大型入口網站都會採用分散式的方式來部署伺服器。當然，如果使用了 cache，記憶體的使用會隨著伺服器執行時間的延長而增加，但是 CPU 通常不會成為關鍵資源。
這是入口網站同企業應用或者線上遊戲的區別。
還是偶：
to 樓主
上面我也提到了，你需要進一步的明確你的測試需求是否有效，合理。
效能需求需要根據網站具體提供的業務型別來作為依據進行衡量。就如同上面提到的，是隻提供了靜態頁面的訪問？還是有其他的業務？
要區分清楚註冊使用者、線上使用者和併發使用者的區別。
另外，你最迫切需要擔心的並不應該是 LR 的 license 問題，而是被測的系統能否支援的了幾百或者幾千併發使用者，如果連這個都支援不了，就更不用考慮上萬的併發訪問了
先是樓主提出問題：
最近公司一個專案,是個入口網站,需要做效能測試,根據專案特點定出了主要測試項和測試方案
一種是測試幾個常用頁面能接受的最大併發數(使用者名稱引數化,設定集合點策略)
一種是測試伺服器長時間壓力下,使用者能否正常操作(使用者名稱引數化,迭代執行指令碼)
還有一種則需要測試伺服器能否接受10萬用戶同時線上操作,但使用的Loadrunner的license只能支援1萬用戶,請問這時該如何制定該方案?
後面跟著大家的回覆：
網友 xingcyx 的回覆：
1、找10臺電腦也沒用，license仍然只支援10000個。
2、找HP支援。當然，前提是你有足夠的錢。
3、測到10000使用者併發。我認為，通常情況下10000使用者併發，支援100000使用者線上，沒有問題的。
網友 jackloo 的回覆：
總的來說這一類的效能指標對大多數軟體來說沒什麼實際意義，更多的是對硬體的要求。
如果是用IIS做應用伺服器的話，單臺可承受的最大併發數不可能達到10萬級，那就必須要使用叢集，通過多臺機器做負載均衡來實現；
如果是用websphere之類的應用伺服器的話，單臺可承受的最大併發數可以達到10萬級，但為效能考慮還是必須要使用叢集，通過多臺機器做負載均衡來實現；
那麼，你只要叢集的伺服器足夠多，10萬併發數當然可以達到了。
通常有1個簡單的計算方式，1個連線產生1個session，每個session在伺服器上有個記憶體空間大小的設定，在NT上是3M，那麼10萬併發就需要300G記憶體，當然實際使用中考慮其他程式也佔用記憶體，所以準備的記憶體數量要求比這個還要多一些。
還有10萬個使用者同時線上，跟10萬個併發數是完全不同的2個概念。這個樓上已經說了。但如何做這個轉換將10萬個同時線上使用者轉換成多少個併發數呢？
這就必須要有大量的歷史日誌資訊來支撐了。系統日誌需要有同時線上使用者數量的日誌資訊，還需要有使用者操作次數的日誌資訊，這2個數據的比例就是你同時線上使用者轉換到併發數的比例。
另外根據經驗統計，對於1個JAVA開發的WEB系統（別的我沒統計過，給不出資料），一般1臺雙CPU、2G記憶體的伺服器上可支援的最大併發數不超過 500個（這個狀態下大部分操作都是超時報錯而且伺服器很容易宕機，其實沒什麼實際意義），可正常使用（單步非大資料量操作等待時間不超過20秒）的最大併發數不超過300個。
假設你的10萬同時線上使用者轉換的併發數是9000個，那麼你最少需要這樣的機器18臺，建議不少於30臺。
當然，你要是買個大型伺服器，裡面裝有200個CPU、256G的記憶體，千兆光纖頻寬，就算是10萬個併發使用者，那速度，也絕對是嗖嗖的。
樓主的回覆：
謝謝jackloo !
再請問如果我想測試10000個使用者同時線上做常用操作的話(每兩秒加一個使用者,一直加到10000),對伺服器的要求有多高?
網友 jackloo 的回覆：
套用1句經典臺詞“高，實在是高”
呵呵。另外暴寒1下，你的設定光全部進入執行狀態就需要接近6個小時。
具體的你可以拿1個系統來壓一下看看，可能會出現以下情況：
1。伺服器宕機；
2。客戶端宕機；
3。從某個時間開始伺服器拒絕請求，客戶端上顯示的全是錯誤；
4。勉強測試完成，但網路堵塞或測試結果顯示時間非常長。假設客戶端和伺服器之間百兆頻寬，百兆/10000=10K，那每個使用者只能得到10K，這個速度接近1個64K的MODEM上網的速度；
另外以上分析全都沒考慮系統的後臺，比如資料庫、中介軟體等。
我從沒遇到你說的這樣的效能需求過，也只好憑感覺隨便掰掰：
1。伺服器方面：上面說的那樣的PC SERVER需要50臺；
2。網路方面：按每個使用者50K，那至少5根百兆頻寬獨享，估計僅僅網路延遲就大概是秒一級的；
3。如果有資料庫，至少是ORACLE，最好是SYSBASE，SQL SERVER是肯定頂不住的。資料庫伺服器至少需要10臺4CPU、16G記憶體的機器；
4。如果有CORBA，那至少再準備10臺4CPU、16G記憶體的機器；
再加上負載均衡、防火牆、路由器和各種軟體等，總之沒個1000萬的資金投入，肯定搞不定。
網友 mybasswood 的回覆：
如果是10萬用戶的話要看做些什麼哈.
比如對於voip來說,假設有10萬用戶的話,伺服器規定每個client至少要在3600秒內到伺服器成功報到一次,否則就被伺服器cancel掉.
client是每隔60秒註冊一次.
所以就要推算在3600秒內,每一個client至少成功報到一次是最少的標準.要10萬用戶在3600秒內被伺服器吃掉才可以---這是最低要求.
最高要求是: 在60秒內所有的10萬用戶去註冊,如果伺服器在60秒可以都吃掉的話,每秒種的平均併發差不多是3334.
最低要求是:在3600秒內所有的10使用者去註冊,如果伺服器在3600秒內都可以吃掉的話,每秒鐘的平均併發使用者差不多是60個.還有一過問題是客戶端要在3600秒內傳送至少60次,至少有一次成功.再加上這些使用者分佈在全球各地的話,這樣數值應該還會有變化的.
下面是偶的看法：
給樓主一個建議吧。
你在公司中的測試環境是一定的，你需要做得是現在這個環境中確認一下系統在當前環境下的實際處理能力。如果還有資源，再做一下可伸縮性的測試。
然後對測試結果進行分析，對系統的處理能力和可伸縮性做一個描述。
當然，要在報告中說明你的測試環境。
另外一位網友robust 的留言：
你的意思是否想用10000個使用者測試結果來推測一下10萬個使用者?
還是如有些老兄說的,測試一下什麼伸縮性測試.然後也來個報告,無非也是想用1萬個來推測10萬個的情況?(評註:那樣的話要你做什麼效能測試,只要計算一下就可以得效能結果了.)
還是如有些老兄說的,這一類的效能指標對大多數軟體來說沒什麼實際意義，更多的是對硬體的要求?(評註:那樣的話要你做什麼效能測試,做什麼效能調優,只要計算一下,新增硬體就可以了.)
實際上,"實踐是檢驗真理的唯一標準!"這句話才是硬道理.只有真實地測試過才知道.任何推測只是推測,並不能反映真實的情況.
至於效能測試工具,LR只是普及率高(市場佔有率高),並不是在效能指標上有優勢.世界上比它厲害的工具有不少,舉個例子siprent通訊公司的avalanche2500,大型計算機實驗室配備的效能測試工具.支援錄製/回放,測試結果分析等.它可以模擬從資料層到應用層的協議,(當然也包含http-web),單個支援100萬併發連線.拿它也可以測試100萬級的併發效能.
又是偶的回覆：
樓上的提到的見解不錯，不過對效能測試的理解有些偏差。
先拋開效能測試工具不談，其實這個問題是討論到一個性能測試到底該怎麼做。
簡單舉個例子，如果你想知道一種新的疫苗對人的作用，是不是要把所有的地球人全部找來每個人打一針試試呢？當然不是，只能是通過試驗和抽樣，然後通過統計學的方法來計算出一個模型，通過樣本的表現來估算總體的特徵。這就是統計學研究的領域，。不過請注意，統計學所包含的內容並不是像樓上的老兄所說的一樣：只要計算一下就可以得效能結果了。
效能測試也同樣如此。
樓主提到的效能需求應該是系統上線以後可能要面臨的壓力，先不討論這個需求是否準確和有效，我們先假定它是有效的。那麼，既然要驗證的是系統在上線以後是否有能力應對10萬用戶同時線上的情況，那麼自然要用生產環境來測試。如果有，那麼 OK，可以作這個測試。至於工具，其實可以由開發人員幫忙寫一些簡單的指令碼負責加壓，再通過其他第三方工具收集測試資料就是了。
但是如果沒有生產環境，只有一臺雙CPU，3G記憶體的 2850 伺服器，怎麼辦？這就好像上面提到的例子。可行的方法是在這臺伺服器上使用不同級別的負載來進行測試，並根據測試資料獲得系統在這種環境下的最佳負載和最大負載，並根據測試資料對負載和資源消耗的情況進行估算，找到它們之間的關係。
一般來說，大型的入口網站不會只用一臺超級超級的伺服器來承擔所有的負載，因為採用負載均衡和叢集技術可以更好的解決這個問題，一定是多臺伺服器分佈在不同的地方，內容通過內容分發網路同步到各臺伺服器上。使用者在訪問時，其實是被應用層或者前端裝置路由到一個合適的伺服器去的。所以在測試時，對於可伸縮性的測試是必需的，一定要了解到 cluster 數量增加時，系統的響應能力是否可以線性的增加，也就是說是否可以承受更大的壓力，為更多的使用者提供服務。
最後總結一下，對於效能測試，要作的是確認系統的響應能力，然後看系統是否可以滿足效能需求。
如果大家有不同的見解，歡迎 PK 討論
繼續偶的回覆：
to jackloo
你所提到的對於硬體資源和軟體資源的要求並不完全準確。因為實際的資源消耗要根據網站所提供的業務型別來推算。
對於大多數入口網站來說，可供訪問的大多是靜態頁面。在使用者訪問時，系統只是返回一個靜態頁面給使用者，並不需要保持 session，而且這種情況下負載主要集中在I/O和網路流量方面——這也是為什麼大型入口網站都會採用分散式的方式來部署伺服器。當然，如果使用了 cache，記憶體的使用會隨著伺服器執行時間的延長而增加，但是 CPU 通常不會成為關鍵資源。
這是入口網站同企業應用或者線上遊戲的區別。
還是偶：
to 樓主
上面我也提到了，你需要進一步的明確你的測試需求是否有效，合理。
效能需求需要根據網站具體提供的業務型別來作為依據進行衡量。就如同上面提到的，是隻提供了靜態頁面的訪問？還是有其他的業務？
要區分清楚註冊使用者、線上使用者和併發使用者的區別。
另外，你最迫切需要擔心的並不應該是 LR 的 license 問題，而是被測的系統能否支援的了幾百或者幾千併發使用者，如果連這個都支援不了，就更不用考慮上萬的併發訪問了