轉一討論帖:如何測試一個門戶網站是否可以支援10萬使用者同時線上?

來源:互聯網
上載者:User
文章目錄
  • Feedback

這個文章的內容比較典型,大家有興趣可以也思考一下。

先是樓主提出問題:

最近公司一個項目,是個門戶網站,需要做效能測試,根據項目特點定出了主要測試項和測試方案
一種是測試幾個常用頁面能接受的最大並發數(使用者名稱參數化,設定集合點策略)
一種是測試伺服器長時間壓力下,使用者能否正常操作(使用者名稱參數化,迭代運行指令碼)
還有一種則需要測試伺服器能否接受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 問題,而是被測的系統能否支援的了幾百或者幾千並發使用者,如果連這個都支援不了,就更不用考慮上萬的並發訪問了。

 

希望大家有不同的看法和意見都可以寫下來,大家一起討論,共同進步。 

Feedback #1樓 [樓主]    回複   引用   查看    

2006-11-16 09:20 by Jackei       後續繼續討論 樓主再次發文:10萬使用者是以後正式上線後客戶預計的數目,我這裡想問下的是1萬使用者線上大概需要的配置是怎樣的?(例每兩秒載入一個使用者共載入1萬個使用者)  偶再次回複:看來樓主還是不明白。

1.大概需要什麼樣的配置是要通過你的測試來評估的;
2.你的 10000 使用者,以及每兩秒載入一個使用者是否是類比實際的情境,是否有參考依據?
3.你提到要測試包括幾個頁面,那麼在這幾個頁面中使用者的分布情況是怎麼樣的?#2樓 [樓主]   回複  引用  查看    

2006-11-16 11:02 by Jackei       大家有興趣的話可以去 51 參加討論 ^_^

http://bbs.51testing.com/thread-48563-1-1.html#3樓    回複  引用    

2006-11-16 17:18 by oscarxie [未註冊使用者] 一般大型網站的採用負載平衡,比如一個購物網站30台伺服器分為WWW部分,SSL部分,WWW部分12台,SSL部分18台,這樣可以保證WWW頁面能夠承受500-600萬使用者訪問,SSL部分可以承受最大2000-3000個使用者同時下訂單。
同時資料庫伺服器要達到一定的規模。#4樓 [樓主]   回複  引用  查看    

2006-11-16 18:29 by Jackei       @oscarxie
謝謝,您提供的這些資料相信更有助於大家對上面討論的理解。#5樓 [樓主]   回複  引用  查看    

2006-11-16 18:34 by Jackei       繼續跟進 網友 robust  的回複:

QUOTE:
原帖由 jackei 於 2006-11-16 11:00 發表

在醫學、生物工程等領域,很多實驗擷取樣本極為困難,使用幾百份樣本來獲得對更大總體的特徵的估算也是合理的。  

沒有錯,因為前提是他們的取樣的方法是科學的,合理的。象這種工程領域的取樣,他們的樣本會是均勻分布的,如果取樣的方法是錯誤的,那他們的結果也是錯誤的。

反觀這個例子,10000個裡取樣,推測10萬這樣的結果,你認為取的樣本分布是什麼分布,是正確的,科學的嗎? 網友 jackloo 的回複:呵呵。精彩。向jackie和robust學習哦。
不過對於LZ說的這樣的門戶系統,由於有使用者權限,所以並不象jackie所說大多是靜態頁面。但只要是多伺服器的叢集,那麼我們就可以通過1台機器的測試結果來計算多台機器叢集後的負載能力的,最多額外考慮一下負載平衡和路由上的壓力,比如頻寬、速度、延遲等。但如果都是在1台機器上變化,那我們只能做一些指標上的計算,可以從這些指標上簡單判斷一下是否不可行,比如10萬並發使用者卻只有1根百兆頻寬,那我們可以計算出每個使用者只有1K頻寬,這顯然是不可行的。但實際的結果還是需要測試了才知道,畢竟系統壓力和使用者數量不是線性變化的。
另外我也解釋一下為什麼說“這一類的效能指標對大多數軟體來說沒什麼實際意義,更多的是對硬體的要求”。
這一類是指最大並發數、最大線上使用者數量等。因為使用者操作不同功能,對系統的壓力就不同,而在實際使用過程中常常會出現因為時間不同或者發生突發事件導致整體使用者操作上功能的變化。所以沒有統一的功能使用的標準導致了這一類的指標成了個噱頭。所有的軟體廠商都是自說自話,把自己的軟體安裝在一個極端的環境中,做一些沒有實際意義的操作,得出一個你永遠都不可能達到的效能指標出來。就如同汽車廠商的汽車油耗一樣,反正你就聽聽罷了,真正使用中是不算數的。
另外這一類系統的普遍的成熟的使用,以及很多軟體在方案設計後就能夠大致估算出系統的效能特點,都導致了系統在軟體效能方面調優的比例並不大(當然不完全排除後期針對某些代碼和配置進行最佳化後效能的進一步提高),更多的都是從硬體方面來考慮,比如增加記憶體、硬碟做RAID、增加頻寬、甚至增加機器等。 偶的回複:HI. robust, 真的很高興有人可以這樣一起討論問題 ^_^

我說說我的看法吧。

首先,對於回應時間之類的這種連續性常態分佈,只要樣本數量夠多,通常都是均勻分布的,也就是說是具有統計學意義的。——什麼叫樣本量夠多?例如 100 個並發使用者執行一次迭代是不夠的,可以考慮每個虛擬使用者執行 100 次迭代,來盡量減少抽樣的隨機性對資料真實性的影響。當然,我們必需瞭解,抽樣的數量是收到時間和相關資源的限制的,個人理解是應該在資源限制的範圍內獲得儘可能多的樣本資料。

第二,其實上面我們在討論的是兩個問題,一個是涉及到效能測試本身,另外一個是如何通過延展性測試(scalability testing),或者說通過容量的規劃來對系統的效能做出預期。

應該說效能測試本身也是一個實驗,但是總體並不是上面提到的 10 萬使用者,而是從這個系統第一個使用者訪問開始到系統下線前的最後一個使用者。通常大家都會用平均回應時間來評估系統效能,但是如果要獲得最準確的平均回應時間,就要記錄這個系統第一個使用者訪問開始到系統下線前的最後一個使用者,每個使用者的回應時間,然後平均。但明顯這是不現實的,就好像我上面提到的那個疫苗的例子。我們只能通過效能測試,通過不同層級的壓力(並發量)來擷取實驗資料,並通過對這些實驗資料的分析獲得對系統真實效能的估算。這裡涉及到 Std.(標準差)和信賴區間等統計學方法,我將會在我的“《LoadRunner沒有告訴你的》之Std.在效能分析中的應用”一文中詳細討論。

而對於延展性測試,對於很多大型網站或電訊廠商級的系統來說是必需的,因為要考慮到使用者的增長,所以必需要瞭解系統在將來是否可以通過一些簡單有效方法(例如增加 cluster)來提高系統的處理能力,以及在當前的階段是否需要投入巨大的資金來購買硬體和各種軟體的 license。通常來說是要根據並發量、系統的效能表現以及軟硬體資源的消耗情況來進行分析,並使用數學建模的方式獲得一個容量模型。這方面可以通過 google 找到更多的資料。

希望這個討論可以繼續下去 ^_^ 還是偶的回複,to 網友 jackloo 呵呵,很高興看到大家都回來繼續討論這個話題,感覺現在我們的討論已經很有深度了,希望可以繼續。

另外,說點個人的看法。

首先,如果驗證使用叢集時系統響應能力的變化,只有一台 cluster 的資料是不夠的,一定需要繼續做 2/3/4 台或者更多(如果有足夠的資源的話)測試,得到的資料和分析的結果才更接近真實情況。

第二,我也同意你提到的“這一類的效能指標對大多數軟體來說沒什麼實際意義,更多的是對硬體的要求”。因為一方面可以看到 樓主 的效能需求本身還是值得商榷的。不過我們也可以反過來想,就是可以驗證在某個環境下,系統所能支援的並發量是多少。例如目前的頻寬是 100 M ,可以支援的並發量是多少,當升級到 1000 M 時,又如何?可以通過以現有環境為基礎的測試來瞭解系統在不同壓力下可能出現的瓶頸,作為將來部署的一個參考。

 

#6樓     回複   引用    

2007-05-26 00:00 by asqcf [未註冊使用者] 人人為我、我為人人。

隨著互連網日益快速發展,網站空間的供應商(IDC)越來越多
一、如何選擇好的IDC
要想選用一個好的IDC,必須選用正規的公司、有信譽、注重品牌形象、開展業務的時間長的公司,畢竟老品牌不會因為某個客戶,影響了多年的品牌形象,還有就是後期的服務保證。其中最重要的一點就是網站的訪問速度和品質的問題了。

二、如何分辨訪問速度和品質
常規做法就是用電腦去PING你所要測試的網站,其結果就是只能測試你這個地區,你所在的網路的訪問速度。這種測試的方法有很大的局限性,不能夠真實的反映出網站的實際情況。也就無法讓急需要找的好的IDC的你。無法做出正確的選擇。

現在好了,由我們為您提供的這款免費軟體能為您解決問題。測測拉網站評估網路測試系統(www.cecela.com)提供網站評估和網路測試服務,可以測試網站、個人、網路電訊廠商、IDC、各地區的網路效能狀況,主要表現為訪問速度、網路穩定性、對比和排名。該系統採用真實用戶端模式,提供24*7的全天候資料監測,能夠按網站應用程式、時間、地區、電訊廠商等不同的維度,全面評估網站服務可訪問性與訪問效果,協助互連網經營者們進行網站應用程式服務的改進和最佳化最終協助實現業務增長和品牌提升。本軟體實行免費使用,您只要登陸下載用戶端並完成註冊即可使用。在你得到您想要的資料的同時,也為其他的註冊使用者進行了測試。這就是此款軟體的使用的真諦---人人為我、我為人人。 原文地址:http://www.cnblogs.com/jackei/archive/2006/11/16/561846.html

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.