LoadRunner壓力測(cè)試結(jié)果分析探討

1、LoadRunner壓力測(cè)試結(jié)果分析探討分析原則:1.具體問題具體分析（這是由于不同的應(yīng)用系統(tǒng)，不同的 測(cè)試目的，不同 的性能關(guān)注點(diǎn)）2. 查找瓶頸時(shí)按以下順序，由易到難。服務(wù)器硬件瓶頸網(wǎng)絡(luò)瓶頸（對(duì)局域網(wǎng)，可以不考慮）服務(wù)器操作系統(tǒng)應(yīng)用瓶頸（參數(shù)配置）中間件瓶頸（參數(shù)配置，數(shù)據(jù)庫(kù),web服務(wù)器等）瓶頸（SQL語(yǔ)句、數(shù)據(jù)庫(kù)設(shè)計(jì)、業(yè)務(wù)邏輯、算法等）分析的信息來(lái)源:1.根據(jù)場(chǎng)景運(yùn)行過程中的錯(cuò)誤提示信息2.根據(jù)測(cè)試結(jié)果收集到的監(jiān)控指標(biāo)數(shù)據(jù).錯(cuò)誤提示分析分析實(shí)例:“30 ： 100601. Error: Failed to connect to server ConnectionEr

2、ror: timed out Error: Server conn ecti on p rematurely“30 has shut down the分析:A應(yīng)用服務(wù)死掉。（小用戶時(shí)：程序上的問題。程序上處理數(shù)據(jù)庫(kù)的問題，實(shí)際測(cè)試中多半是 服務(wù)器鏈接的配置問題）B、應(yīng)用服務(wù)沒有死（應(yīng)用服務(wù)參數(shù)設(shè)置問題）對(duì)應(yīng)的Apache和tomcat的最大鏈接數(shù)需要修改，如果連接時(shí)收到 connection refused 消息，說明應(yīng)提高相應(yīng)的服務(wù)器最大連接的設(shè)置，增加幅 度要根據(jù)實(shí)際情況和服務(wù)器硬件的情況來(lái)定，建議每次增加25%!C數(shù)據(jù)庫(kù)的連接（數(shù)據(jù)庫(kù)啟動(dòng)的最大連接數(shù)（跟硬件的內(nèi)存有關(guān)

3、） ）D我們的應(yīng)用程序spring控制的最大鏈接數(shù)太低2. Error: Page download timeout (120 seconds) has expired分析：A、應(yīng)用服務(wù)參數(shù)設(shè)置太大導(dǎo)致服務(wù)器的瓶頸B、頁(yè)面中圖片太多C、在程序處理表的時(shí)候檢查字段太大多D、實(shí)際測(cè)試時(shí)有些資源需要請(qǐng)求外網(wǎng)，而我們的測(cè)試環(huán)境是局域網(wǎng)環(huán)境3. Error“30/Home.do 分析：A腳本設(shè)計(jì)錯(cuò)誤，造成頁(yè)面異常。服務(wù)器有響應(yīng)!B、并發(fā)數(shù)過大，造成服務(wù)器響應(yīng)延遲。4. Error page“text=xxxxx ”分析：A腳本設(shè)計(jì)問題，例如，前一腳本修改了某些內(nèi)容，造成后

4、面的腳本訪問 異常。B、不確定因素，有時(shí)候回放正常的腳本，一放到場(chǎng)景中就出現(xiàn)這樣的錯(cuò)誤。 只能反復(fù)修改腳本!監(jiān)控指標(biāo)數(shù)據(jù)分析1Vusers 數(shù)Loadrunner 系統(tǒng)設(shè)置的虛擬用戶數(shù)目。 Vuser 去實(shí)際調(diào)用事先制作的腳本 文件中的應(yīng)用。每個(gè) Vuser 產(chǎn)生響應(yīng)的操作，所有的操作對(duì)服務(wù)器形成并發(fā)。顏色 比例 度量 圖最小值 圖平均值 圖最大值 圖中間值 圖 SD1 Run 0.0 21.25 44 41 21.276在實(shí)際測(cè)試中， Vusers 可以根據(jù)實(shí)際情況的需要，在測(cè)試過程中增加或者 減少。2最大并發(fā)用戶數(shù)：顏色 比例 度量 最小值 平均值 最大值 SD100 Apache CPU

5、使用情況(Apache):100.777 0.852 0.93 0.0430.01 已發(fā)送 KB/ 秒(Apache):106 1430.371 2689.333 327.9240.1 點(diǎn)擊次數(shù) / 秒(Apache):10 0.333 114.352 533.667 40.201應(yīng)用系統(tǒng)在當(dāng)前環(huán)境下能承受的最大并發(fā)用戶數(shù)。在方案運(yùn)行中，如果出現(xiàn)了大批用戶的業(yè)務(wù)操作失敗，或出現(xiàn)了服務(wù)器 shutdown 的情況，則說明在當(dāng)前環(huán)境下，系統(tǒng)承受不了當(dāng)前并發(fā)用戶的負(fù)載壓 力，那么最大并發(fā)用戶數(shù)就是前一個(gè)沒有出現(xiàn)這種現(xiàn)象的并發(fā)用戶數(shù)。從上圖可

6、以看出：在測(cè)試運(yùn)行到 4個(gè)小時(shí)左右的時(shí)候， apache 的點(diǎn)擊數(shù) /秒 開始迅速增加！3業(yè)務(wù)操作響應(yīng)時(shí)間：使用 “事務(wù)性能摘要 ”圖，可以確定在方案執(zhí)行期間響應(yīng)時(shí)間過長(zhǎng)的事務(wù)。顏色 比例 度量1 最小值1 平均值1 最大值分析事務(wù)的響應(yīng)情況， 要每次詳細(xì)分析， 目前還只能觀察到響應(yīng)時(shí)間過長(zhǎng)的事務(wù)！4每秒點(diǎn)擊數(shù)負(fù)載測(cè)試期間每秒內(nèi) Vuser 在 Web 服務(wù)器上點(diǎn)擊的次數(shù)。 可根據(jù)點(diǎn)擊次數(shù)來(lái)估算 Vuser 生成的負(fù) 載數(shù)。顏色 比例 度量 圖最小值 平均值 圖最大值 圖中間值 圖 SD1 點(diǎn)擊次數(shù) 69.908 105.736 130.244 103.666 12.186從圖中不難看出，在

7、4 小時(shí)的時(shí)候，點(diǎn)技數(shù)明顯增高。和 apache 的每秒點(diǎn)擊數(shù)增大的時(shí)間相吻合！5吞吐量負(fù)載測(cè)試期間 Web 服務(wù)器上的吞吐量 （字節(jié) ）。吞吐量表示在任何指定秒內(nèi) Vuser 從服務(wù)器接收到的 數(shù)據(jù)量。此圖可估計(jì) Vuser 生成的負(fù)載量 （服務(wù)器吞吐量 ）。顏色 比例 度量 圖最小值 平均值 圖最大值 圖中間值 圖 SD1 Throughput 1257502.795 1375591.372 1525865.047 1372743.691 49130.473同樣，從圖中可以看出，在 4 個(gè)小時(shí)的時(shí)候， web 服務(wù)器的吞吐量開始增高。在圖中還可以看到吞吐 量的走勢(shì)圖，從開始到進(jìn)行到 4 個(gè)

8、小時(shí)反彈之前呈降低的趨勢(shì)，這是因?yàn)橄到y(tǒng)在初期調(diào)用的資源都是直接 來(lái)之服務(wù)器，運(yùn)行一段時(shí)間后系統(tǒng)的部分資源來(lái)自緩存。6下載組件大小每個(gè)頁(yè)面的組件大小，且包括組件的標(biāo)頭的大??！loadrunner 的報(bào)告分析工具來(lái)分析。頁(yè)面組頁(yè)面組件大小的分析表格比較復(fù)雜，實(shí)際分析中可以通過件大小分析主要是找到頁(yè)面中比較龐大的組件，如果其影響到了頁(yè)面的下載速度，則要想辦法將其改??！7 Apache 資源顯示 APACHE web 服務(wù)器上的資源摘要。前面已經(jīng)提到過以并發(fā)點(diǎn)擊數(shù)為主。顏色 比例 度量 最小值 平均值 最大值 SD100 Apache CPU 使用情況 (Apache):10 0.

9、777 0.852 0.93 0.0430.01 已發(fā)送 KB/ 秒(Apache):10 6 1430.371 2689.333 327.9240.1 點(diǎn)擊次數(shù) /秒(Apache):10 0.333 114.352 533.667 40.201三服務(wù)器資源監(jiān)控指標(biāo)：目前通過 top 監(jiān)察）內(nèi)存：Linux 資源監(jiān)控中指標(biāo)內(nèi)存頁(yè)交換速率（ Paging rate ），如果該值偶爾走高，表明當(dāng)時(shí)有線程競(jìng)爭(zhēng)內(nèi) 存。如果持續(xù)很高，則內(nèi)存可能是瓶頸。也可能是內(nèi)存訪問命中率低。實(shí)際測(cè)試中，當(dāng)并發(fā)點(diǎn)擊數(shù)出現(xiàn)突然劇增前后， 中內(nèi)存存在瓶頸！內(nèi)存的PR 值則居高 25

10、 不下。說明目前測(cè)試的系統(tǒng)內(nèi)存資源成為系統(tǒng)性能的瓶頸的征兆很高的換頁(yè)率 (high pageout rate);進(jìn)程進(jìn)入不活動(dòng)狀態(tài) ;交換區(qū)所有磁盤的活動(dòng)次數(shù)可高可高的全局系統(tǒng) CPU 利用率 ;內(nèi)存不夠出錯(cuò) (out of memory errors)處理器：Linux 資源監(jiān)控中指標(biāo) CPU 占用率持續(xù)超過 同，有資料表明 95 ），表明瓶頸是 CPU 。80%（對(duì)該值的要求， 根據(jù)具體應(yīng)用和機(jī)器配置而要求不實(shí)際測(cè)試中， 當(dāng)并發(fā)點(diǎn)技數(shù)出現(xiàn)突然增加前后，cpu 的占用率持續(xù)保持在 8 6 以上！說明，目前系統(tǒng)用應(yīng)用的 cpu 也是測(cè)試的瓶頸！CPU 資源成為系統(tǒng)性能的瓶頸的征兆很慢的響應(yīng)時(shí)間

11、 (slow response time)CPU 空閑時(shí)間為零 (zero percent idle CPU)過高的用戶占用 CPU 時(shí)間 (high percent user CPU)過高的系統(tǒng)占用 CPU時(shí)間(high percent system CPU)長(zhǎng)時(shí)間的有很長(zhǎng)的運(yùn)行進(jìn)程隊(duì)歹y(large run queue size sustained over time)四.數(shù)據(jù)庫(kù)服務(wù)器:數(shù)據(jù)庫(kù)服務(wù)器目前測(cè)試觀察，當(dāng)web服務(wù)器點(diǎn)擊率增大時(shí)，觀察 mysql數(shù)據(jù)庫(kù)的最大連接數(shù)，仍未超過系統(tǒng)設(shè)置的最大連接數(shù)。所以，暫時(shí)未發(fā)現(xiàn)數(shù)據(jù)庫(kù)的瓶頸！五.結(jié)論以上報(bào)告分析中的數(shù)據(jù)、圖標(biāo)均來(lái)自同一次測(cè)試。是在

12、平時(shí)測(cè)試中挑出的一次現(xiàn)象比較明顯，比較利 于觀察的作為分析案例。根據(jù)以上綜合分析，當(dāng)前測(cè)試環(huán)境下，當(dāng)應(yīng)用系統(tǒng)產(chǎn)生最大 533.667的并發(fā)壓力。平均負(fù)載壓力 114.352。根據(jù)分析，用戶在 4個(gè)小時(shí)的時(shí)候，并發(fā)數(shù)迅速增加前后的值在400左右！分析結(jié)果跟實(shí)際測(cè)試的硬件環(huán)境以及測(cè)試腳本有一定關(guān)系。同時(shí)，測(cè)試服務(wù)器的硬件配置和實(shí)際服務(wù)器的配置還有一定的差 距！轉(zhuǎn)一份在51testing上的討論一一如何測(cè)試一個(gè)門戶網(wǎng)站是否可以支持10萬(wàn)用戶同時(shí)在線?Posted on 2006-11-16 01:21類：04.軟件性能測(cè)試.Jackei閱讀（6074） 評(píng)論 編輯 收藏 網(wǎng)摘 所屬分這個(gè)帖子的內(nèi)容比

13、較典型，大家有興趣可以也思考一下。先是樓主提出問題:亠最近公司一個(gè)項(xiàng)目，是個(gè)門戶網(wǎng)站，需要做性能測(cè)試，根據(jù)項(xiàng)目特點(diǎn)定出了主要測(cè)試項(xiàng)和測(cè) 試方案=一種是測(cè)試幾個(gè)常用頁(yè)面能接受的最大并發(fā)數(shù)（用戶名參數(shù)化，設(shè)置集合點(diǎn)策略）二一種是測(cè)試服務(wù)器長(zhǎng)時(shí)間壓力下，用戶能否正常操作（用戶名參數(shù)化，迭代運(yùn)行腳本）還有一種則需要測(cè)試服務(wù)器能否接受10萬(wàn)用戶同時(shí)在線操作，但使用的Loadrunner的Iicense只能支持1萬(wàn)用戶，請(qǐng)問這時(shí)該如何制定該方案？后面跟著大家的回復(fù):網(wǎng)友xingcyx 的回復(fù):=1、2、找10臺(tái)電腦也沒用，license仍然只支持10000個(gè)。找HP支持。當(dāng)然，前提是你有足夠的錢。測(cè)到10

14、000用戶并發(fā)。我認(rèn)為，通常情況下10000用戶并發(fā)，支持100000 用戶在線，沒有問題的。網(wǎng)友jackloo 的回復(fù):二總的來(lái)說這一類的性能指標(biāo)對(duì)大多數(shù)軟件來(lái)說沒什么實(shí)際意義，更多的是對(duì)硬件的要求。如果是用IIS做應(yīng)用服務(wù)器的話，單臺(tái)可承受的最大并發(fā)數(shù)不可能達(dá)到10萬(wàn)級(jí)，那就必須要使用集群，通過多臺(tái)機(jī)器做負(fù)載均衡來(lái)實(shí)現(xiàn)；10萬(wàn)_如果是用websphere 之類的應(yīng)用服務(wù)器的話，單臺(tái)可承受的最大并發(fā)數(shù)可以達(dá)到 級(jí)，但為性能考慮還是必須要使用集群，通過多臺(tái)機(jī)器做負(fù)載均衡來(lái)實(shí)現(xiàn)； 一那么，你只要集群的服務(wù)器足夠多，10萬(wàn)并發(fā)數(shù)當(dāng)然可以達(dá)到了。通常有1個(gè)簡(jiǎn)單的計(jì)算方式，1個(gè)連接產(chǎn)生1個(gè)sessio

15、n ，每個(gè)session在服務(wù)器上有個(gè) 內(nèi)存空間大小的設(shè)置，在 NT上是3M，那么10萬(wàn)并發(fā)就需要300G內(nèi)存，當(dāng)然實(shí)際使用 中考慮其他程序也占用內(nèi)存，所以準(zhǔn)備的內(nèi)存數(shù)量要求比這個(gè)還要多一些。還有10萬(wàn)個(gè)用戶同時(shí)在線，跟 10萬(wàn)個(gè)并發(fā)數(shù)是完全不同的 2個(gè)概念。這個(gè)樓上已經(jīng)說 了。但如何做這個(gè)轉(zhuǎn)換將 10萬(wàn)個(gè)同時(shí)在線用戶轉(zhuǎn)換成多少個(gè)并發(fā)數(shù)呢？ 一這就必須要有大量的歷史日志信息來(lái)支撐了。系統(tǒng)日志需要有同時(shí)在線用戶數(shù)量的日志信息，還需要有用戶操作次數(shù)的日志信息，這2個(gè)數(shù)據(jù)的比例就是你同時(shí)在線用戶轉(zhuǎn)換到并發(fā)數(shù)的比例。500個(gè)（這個(gè)狀態(tài)下大 ，可正常使用（單步 個(gè)。假設(shè)你的10萬(wàn)同時(shí)在線用戶轉(zhuǎn)換的并發(fā)數(shù)

16、是9000個(gè)，那么你最少需要這樣的機(jī)器18臺(tái)，建議不少于 30臺(tái)。當(dāng)然，你要是買個(gè)大型服務(wù)器，里面裝有200個(gè)CPU、256G的內(nèi)存，千兆光纖帶寬，就算是10萬(wàn)個(gè)并發(fā)用戶，那速度，也絕對(duì)是嗖嗖的。一另外根據(jù)經(jīng)驗(yàn)統(tǒng)計(jì)，對(duì)于 1個(gè)JAVA開發(fā)的WEB系統(tǒng)（別的我沒統(tǒng)計(jì)過，給不出數(shù)據(jù)） 一般1臺(tái)雙CPU、2G內(nèi)存的服務(wù)器上可支持的最大并發(fā)數(shù)不超過 部分操作都是超時(shí)報(bào)錯(cuò)而且服務(wù)器很容易宕機(jī)，其實(shí)沒什么實(shí)際意義） 非大數(shù)據(jù)量操作等待時(shí)間不超過20秒）的最大并發(fā)數(shù)不超過 300樓主的回復(fù):謝謝 jackloo !一再請(qǐng)問如果我想測(cè)試10000 個(gè)用戶同時(shí)在線做常用操作的話（每?jī)擅爰右粋€(gè)用戶，一直加到100

17、00）,對(duì)服務(wù)器的要求有多高 ？網(wǎng)友jackloo的回復(fù)：高，實(shí)在是高”下，你的設(shè)置光全部進(jìn)入運(yùn)行狀態(tài)就需要接近6個(gè)小時(shí)。個(gè)系統(tǒng)來(lái)壓一下看看，可能會(huì)出現(xiàn)以下情況：=套用1句經(jīng)典臺(tái)詞二呵呵。另外暴寒1體的你可以拿1 _1。服務(wù)器宕機(jī)；2?？蛻舳隋礄C(jī)；_3。從某個(gè)時(shí)間開始服務(wù)器拒絕請(qǐng)求，客戶端上顯示的全是錯(cuò)誤；4。勉強(qiáng)測(cè)試完成，但網(wǎng)絡(luò)堵塞或測(cè)試結(jié)果顯示時(shí)間非常長(zhǎng)。假設(shè)客戶端和服務(wù)器之間百比如數(shù)據(jù)庫(kù)、中間件等。 也只好憑感覺隨便掰掰：PC SERVER 需要 50 臺(tái);兆帶寬，百兆/10000=10K ，那每個(gè)用戶只能得到 10K，這個(gè)速度接近1個(gè)64K的MOD EM上網(wǎng)的速度；_ 另外以上分析全都

18、沒考慮系統(tǒng)的后臺(tái)，_ 我從沒遇到你說的這樣的性能需求過， 1。服務(wù)器方面：上面說的那樣的2。網(wǎng)絡(luò)方面：按每個(gè)用戶 50K，那至少5根百兆帶寬獨(dú)享，估計(jì)僅僅網(wǎng)絡(luò)延遲就大概是 秒一級(jí)的；3。如果有數(shù)據(jù)庫(kù)，至少是ORACLE，最好是 SYSBASE，SQL SERVER 是肯定頂不住的。數(shù)據(jù)庫(kù)服務(wù)器至少需要10臺(tái)4CPU、16G內(nèi)存的機(jī)器；二4。如果有CORBA，那至少再準(zhǔn)備10臺(tái)4CPU、16G內(nèi)存的機(jī)器；再加上負(fù)載均衡、防火墻、路由器和各種軟件等，總之沒個(gè)1000萬(wàn)的資金投入，肯定搞不定。網(wǎng)友 mybasswood的回復(fù)：_如果是10萬(wàn)用戶的話要看做些什么哈.比如對(duì)于voip來(lái)說，假設(shè)有10萬(wàn)用

19、戶的話，服務(wù)器規(guī)定每個(gè) client至少要在3600秒內(nèi) 到服務(wù)器成功報(bào)到一次，否則就被服務(wù)器cancel掉._client是每隔60秒注冊(cè)一次.二所以就要推算在 3600秒內(nèi),每一個(gè)client至少成功報(bào)到一次是最少的標(biāo)準(zhǔn).要10萬(wàn)用戶在3600秒內(nèi)被服務(wù)器吃掉才可以-這是最低要求.最高要求是：在60秒內(nèi)所有的10萬(wàn)用戶去注冊(cè)，如果服務(wù)器在60秒可以都吃掉的話，每 秒種的平均并發(fā)差不多是3334.飛低要求是：在3600秒內(nèi)所有的10用戶去注冊(cè)，如果服務(wù)器在3600秒內(nèi)都可以吃掉的 話，每秒鐘的平均并發(fā)用戶差不多是 60個(gè).還有一過問題是客戶端要在 3600秒內(nèi)發(fā)送至少 60次,至少有一次成功

20、.再加上這些用戶分布在全球各地的話 ，這樣數(shù)值應(yīng)該還會(huì)有變化的.下面是偶的看法:給樓主一個(gè)建議吧。你在公司中的測(cè)試環(huán)境是一定的，你需要做得是現(xiàn)在這個(gè)環(huán)境中確認(rèn)一下系統(tǒng)在當(dāng)前環(huán)境下的實(shí)際處理能力。如果還有資源，再做一下可伸縮性的測(cè)試。然后對(duì)測(cè)試結(jié)果進(jìn)行分析，對(duì)系統(tǒng)的處理能力和可伸縮性做一個(gè)描述。當(dāng)然，要在報(bào)告中說明你的測(cè)試環(huán)境。另外一位網(wǎng)友robust 的留言:二你的意思是否想用10000個(gè)用戶測(cè)試結(jié)果來(lái)推測(cè)一下10萬(wàn)個(gè)用戶？還是如有些老兄說的，測(cè)試一下什么伸縮性測(cè)試.然后也來(lái)個(gè)報(bào)告，無(wú)非也是想用1萬(wàn)個(gè)來(lái) 推測(cè)10萬(wàn)個(gè)的情況?（評(píng)注：那樣的話要你做什么性能測(cè)試，只要計(jì)算一下就可以得性能結(jié)果了 .

21、）還是如有些老兄說的，這一類的性能指標(biāo)對(duì)大多數(shù)軟件來(lái)說沒什么實(shí)際意義，更多的是對(duì) 硬件的要求?（評(píng)注:那樣的話要你做什么性能測(cè)試，做什么性能調(diào)優(yōu)，只要計(jì)算一下，添加硬件就可以了 .）實(shí)際上，實(shí)踐是檢驗(yàn)真理的唯一標(biāo)準(zhǔn)!這句話才是硬道理.只有真實(shí)地測(cè)試過才知道.任何推測(cè)只是推測(cè)，并不能反映真實(shí)的情況.至于性能測(cè)試工具丄R只是普及率高（市場(chǎng)占有率高），并不是在性能指標(biāo)上有優(yōu)勢(shì).世界上 比它厲害的工具有不少，舉個(gè)例子siprent通信公司的avalanche2500，大型計(jì)算機(jī)實(shí)驗(yàn)室配備的性能測(cè)試工具.支持錄制/回放,測(cè)試結(jié)果分析等.它可以模擬從數(shù)據(jù)層到應(yīng)用層的協(xié)議 （當(dāng)然也包含http-web）,單

22、個(gè)支持100萬(wàn)并發(fā)連接.拿它也可以測(cè)試100萬(wàn)級(jí)的并發(fā)性能.又是偶的回復(fù):樓上的提到的見解不錯(cuò)，不過對(duì)性能測(cè)試的理解有些偏差。先拋開性能測(cè)試工具不談，其實(shí)這個(gè)問題是討論到一個(gè)性能測(cè)試到底該怎么做。簡(jiǎn)單舉個(gè)例子，如果你想知道一種新的疫苗對(duì)人的作用，是不是要把所有的地球人全部找 來(lái)每個(gè)人打一針試試呢？當(dāng)然不是，只能是通過試驗(yàn)和抽樣，然后通過統(tǒng)計(jì)學(xué)的方法來(lái)計(jì)算出一個(gè)模型，通過樣本的表現(xiàn)來(lái)估算總體的特征。這就是統(tǒng)計(jì)學(xué)研究的領(lǐng)域，。不過請(qǐng)注意,統(tǒng)計(jì)學(xué)所包含的內(nèi)容并不是像樓上的老兄所說的一樣：只要計(jì)算一下就可以得性能結(jié)果了。性能測(cè)試也同樣如此。10K ,可以作這個(gè)再通過其他第三方_ 樓主提到的性能需求應(yīng)該

23、是系統(tǒng)上線以后可能要面臨的壓力， 先不討論這個(gè)需求是否準(zhǔn)確 和有效，我們先假定它是有效的。那么，既然要驗(yàn)證的是系統(tǒng)在上線以后是否有能力應(yīng)對(duì)0萬(wàn)用戶同時(shí)在線的情況，那么自然要用生產(chǎn)環(huán)境來(lái)測(cè)試。如果有，那么 測(cè)試。至于工具，其實(shí)可以由開發(fā)人員幫忙寫一些簡(jiǎn)單的腳本負(fù)責(zé)加壓， 工具收集測(cè)試數(shù)據(jù)就是了。怎么辦？這就好像 并根據(jù)測(cè) 并根據(jù)測(cè)試數(shù)據(jù)對(duì)負(fù)載和資源消耗的但是如果沒有生產(chǎn)環(huán)境，只有一臺(tái)雙CPU , 3G內(nèi)存的2850服務(wù)器，上面提到的例子?？尚械姆椒ㄊ窃谶@臺(tái)服務(wù)器上使用不同級(jí)別的負(fù)載來(lái)進(jìn)行測(cè)試, 試數(shù)據(jù)獲得系統(tǒng)在這種環(huán)境下的最佳負(fù)載和最大負(fù)載， 情況進(jìn)行估算，找到它們之間的關(guān)系。_一般來(lái)說，大型的門戶網(wǎng)站