系統(tǒng)性能測試報告V2.0

1、“*”“*”綜合信息平臺（一期）綜合信息平臺（一期） 性能測試報告性能測試報告 *有限公司 文件標識： 文件編號： 當前版本：v1.0 作 者： 公 司： 文件狀態(tài)： 草稿 正式發(fā)布 正在修改 完成日期： 版本控制版本控制 版本號版本號作者作者參與者參與者起止日期起止日期備注備注 目 錄 1.文檔說明文檔說明 .1 1.1標識.1 1.2文檔概述.1 1.3文檔編寫目的.1 1.4名詞解釋.2 1.5參考資料.2 1.6修改約束.2 2.項目背景項目背景 .2 2.1項目基本信息定義.2 2.2項目背景.3 2.3建設目標及范圍.6 2.3.1“*”總體目標.6 2.3.2本期項目建設目標.9

2、 2.3.3本期建設內(nèi)容.9 2.3.4本期與“*”總體規(guī)劃關系.9 3.測試目的測試目的 .10 4.測試工具測試工具 .10 5.性能需求性能需求 .10 6.測試目標測試目標 .11 7.測試環(huán)境與配置測試環(huán)境與配置 .11 7.1網(wǎng)絡環(huán)境描述.11 7.2測試環(huán)境描述.12 7.3真實環(huán)境模擬圖.13 8.測試策略測試策略 .13 測試數(shù)據(jù)準備.13 9.測試結果及分析測試結果及分析 .14 9.1一般性能測試.14 9.2并發(fā)測試.16 9.3負載測試.21 10.性能測試總結性能測試總結 .23 1. 文檔說明文檔說明 1.1標識標識 1.文檔標題文檔標題 2.縮略語縮略語 1.2

3、文檔概述文檔概述 1.3文檔編寫目的文檔編寫目的 性能測試的主要目的如下： 驗證在并發(fā)連接數(shù)量達到用戶所要求的正常并發(fā)連接數(shù)量時，系統(tǒng)的核心 功能/業(yè)務的執(zhí)行是否滿足性能指標要求； 驗證并發(fā)連接數(shù)量達到最大值時，系統(tǒng)的運行狀況； 驗證 j2ee 體系結構中，各層應用的性能情況，并找出性能瓶頸； 驗證系統(tǒng)在使用高峰階段，對大數(shù)據(jù)量的處理是否正常； 本文檔的預期讀者包括本公司項目領導、開發(fā)人員、實施人員和測試人員 等項目干系人。 1.4名詞解釋名詞解釋 性能測試：性能測試： 指為了評估軟件系統(tǒng)的性能狀況和預測軟件系統(tǒng)性能趨勢而進行的測試和分析。 一般通過自動化的測試工具模擬多種正常、峰值以及異常負

4、載條件來對系統(tǒng)的各項 性能指標進行測試。 響應時間：響應時間： 對請求做出響應所需要的時間。 并發(fā)用戶數(shù)：并發(fā)用戶數(shù)： 指同時向服務端發(fā)出請求的客戶數(shù)。 吞吐量：吞吐量： 單位時間內(nèi)系統(tǒng)處理的客戶請求的數(shù)量。 性能計數(shù)器：性能計數(shù)器： 描述服務器或操作系統(tǒng)性能的一些數(shù)據(jù)指標。 1.5參考資料參考資料 1.6修改約束修改約束 該文檔在正式發(fā)布后，其更新需要合作雙方共同確認。 2. 項目背景項目背景 項目基本信息定義項目基本信息定義 2.2項目背景項目背景 2.3建設目標及范圍建設目標及范圍 “*”總體目標總體目標 近期建設目標（近期建設目標（2011-2012 年）年） 2.3.

5、1.2 中期建設目標（中期建設目標（2013-2014 年）年） 遠期建設目標（遠期建設目標（2015 年）年） 2.3.2 本期項目建設目標本期項目建設目標 2.3.3 本期建設內(nèi)容本期建設內(nèi)容 2.3.4 本期與本期與“*”總體規(guī)劃關系總體規(guī)劃關系 3. 測試目的測試目的 1. 測試特定業(yè)務的運行情況，取得大量并發(fā)用戶操作下的響應時間 2. 對測試中發(fā)現(xiàn)的問題給出建議，如果存在性能問題，查找性能瓶頸，進行 性能調優(yōu)。 3. 測試軟件在運行過程中，運行達到用戶標準值。 4. 測試工具測試工具 本次性能測試主要采用 loadrunner 工具，它是一款國際主流與權威的性能 測試

6、工具，它通過錄制腳本記錄客戶端與服務器之間的交互，然后通過回放腳本模 擬出大量的虛擬用戶加載到服務器上，并采用實時監(jiān)控，監(jiān)控服務器與客戶端的多 項性能指標以完成對被測軟件的性能評估。 5. 性能需求性能需求 可以借用目前使用廣泛的基于 tpc-c 的經(jīng)驗公式，來對三個典型應用系統(tǒng)要求進 行估算。其計算公式為： tpmctaskctsf/t(1c) 其中：task 為每日業(yè)務訪問量統(tǒng)計峰值； ct 為系統(tǒng)訪問集中期內(nèi)訪問量比例； t 為每日峰值訪問時間； s 為實際業(yè)務訪問操作的復雜程度比例； c 為系統(tǒng)主機 cpu 處理余量； f 為系統(tǒng)未來 10 年的訪問量發(fā)展。 截止到 2010 年 11

7、 月，頤和園局域網(wǎng)信息接入點 260 個，聯(lián)入辦公網(wǎng)電腦 192 臺， 開通互聯(lián)網(wǎng)電腦 157 臺，約占總數(shù)的 82。根據(jù)以上數(shù)字統(tǒng)計，業(yè)務系統(tǒng)運行后用戶總 數(shù)將達到 315 臺，所有用戶均需要訪問相關的業(yè)務應用系統(tǒng)，按平均每個用戶每天不少 于 8 次訪問計算，則三個典型業(yè)務應用系統(tǒng)的日均訪問量總計不低于 2520 人次，暫按 2500 人次計算。根據(jù)歷史記錄，高峰時期業(yè)務量約為平均業(yè)務量的 1.5 倍，三個典型業(yè) 務應用系統(tǒng)運行后，需要充分考慮系統(tǒng)的可擴展性，因此，估算高峰時期的訪問量約為 平均訪問量的 3 倍平均每次訪問對應數(shù)據(jù)庫事務數(shù)為 20，則 task2500203150,000；

8、訪問時間大部分集中在上班時間，故取 t=6h，同時根據(jù)經(jīng)驗取 ct=80%； 根據(jù)系統(tǒng)響應訪問服務的分類，統(tǒng)計分析服務屬于復雜操作，復合查詢等屬于一般 操作，而信息檢索瀏覽屬于簡單操作，三個典型應用系統(tǒng)業(yè)務中三類操作所占比例大致 為 25%、30%、45%，則根據(jù)經(jīng)驗權重公式： s25%10030%1045%128.5； c 取值一般為 30%45%，參考同類型項目，取 40%； 根據(jù)預測，應用平臺業(yè)務年平均增長率約為 5.3%，則： f(15.3%)101.68； 將上述數(shù)據(jù)帶入計算公式 tpmctaskctsf/t(1c)，得：tpmc =15000080%28.51.68/660(140

9、%) = 26600 可見，三個典型應用系統(tǒng)的訪問量與需要處理的訪問事務量是非常大的，三個典型 應用系統(tǒng)的建設是非常必要的。 6. 測試目標測試目標 對于專業(yè)的分析功能，提供單次訪問時一般地圖操作 3 秒，復雜操作 5 秒的響 應性能；對于基于圖片引擎的訪問接口，提供單次訪問 1 秒以內(nèi)，復雜操作 3 秒 以內(nèi)的相應性能。高峰時并發(fā)用戶不低于 500 人。系統(tǒng)可同時負載 1000 用戶持續(xù) 半小時以上操作，系統(tǒng)響應一切正常。 7. 測試環(huán)境測試環(huán)境與配置與配置 網(wǎng)絡環(huán)境描述網(wǎng)絡環(huán)境描述 公司內(nèi)部的以太網(wǎng)，與服務器的連接速率為 100m，與客戶端的連接速率為 10/100m 自適應。 7.2測試

10、環(huán)境描述測試環(huán)境描述 服務端 設設 備備硬硬 件件 配配 置置軟軟 件件 配配 置置 web 服務器 pc 機（一臺） cpu：酷睿 內(nèi)存：64g 數(shù)據(jù)庫 cpu:g620 2.60hz,主頻 2.0ghz； mem:8gb ddr3 1333/1066 mhz 內(nèi)存; net: 集成 intel 雙千兆網(wǎng)卡； disk:3*300gb。 sql server 2008 負載產(chǎn)生設備 pc 機（一臺） cpu：酷睿 e5300 內(nèi)存：3g windows xp server loadrunner 11.00 microsoft office 測試地址 67:8

11、090/cas/login 客戶端 設備名稱設備名稱：測試客戶端測試客戶端 ip 地址：1 用途：運行測試腳本 硬件配置： cpu：e5300 內(nèi)存：4gb 硬盤：400gb 軟件配置： 操作系統(tǒng)：windows xp 其它：loadrunner 11.00、ie8 7.3真實環(huán)境模擬圖真實環(huán)境模擬圖 數(shù)據(jù)庫服務器 建設服務器 gige 數(shù)據(jù)庫服務器 主干網(wǎng) 門戶、共享服 務器 園林服務器 文物服務器 容量為14.4tb netstor isum530 8gb光纖盤柜陣列 圖例 8gb fc 千兆以太網(wǎng) quantum scalar i80 物 理磁帶庫 互為鏡像 8gb

12、 san 交換機 16口 8gb san 交換機 16口 數(shù)據(jù)庫系統(tǒng) 構成雙機 各應用系統(tǒng) 構成群集系 統(tǒng) 備份主服務 器安裝備份 軟件 容量為14.4tb netstor isum530 8gb光纖盤柜陣列 備份路徑 ad域服務器 圖 6-1 網(wǎng)路拓撲圖 8. 測試策略測試策略 這次性能測試將結合用戶在日常工作中的實際操作情況對用戶量較大的模塊進 行性能測試，選取公眾版系統(tǒng)的登陸、服務訪問、地圖訪問、查詢功能作為這次性 能測試的對象，并且在此基礎上進行組合，設計綜合場景進行性能測試。 測試數(shù)據(jù)準備測試數(shù)據(jù)準備 為模擬生產(chǎn)環(huán)境情況,設定如下基礎數(shù)據(jù)： 模擬用戶 500 個 模擬并發(fā)用戶 50、

13、100、200、300 個 數(shù)據(jù)庫存放 100w 條以上數(shù)據(jù)量 9. 測試結果及分析測試結果及分析 9.1一般性能測試一般性能測試 場景描述：場景描述：此場景測試 500 個用戶訪問系統(tǒng)的運行情況。 場景設計：場景設計：每 10 秒加載登錄 4 個用戶，持續(xù)增加在線用戶，系統(tǒng)成功加載 500 虛擬用戶在線后，所有用戶在線持續(xù) 5 分鐘后，以每 10 秒 5 個用戶退出系統(tǒng)。不 考慮 think time。 測試重點：測試重點：頁面響應時間，服務器的 cpu、內(nèi)存使用情況。 測試結果：測試結果： 服務器資源檢測如下圖： 說明：cpu 利用率最大值 32.552%，小于標準值 80%。磁盤驅動器讀

14、寫和寫入請 求的最小值為 0.096%，值較小表明目前系統(tǒng)真實環(huán)境硬件不存在瓶頸。 用戶訪問點擊數(shù)如下圖： 說明：在加載到 500 個用戶的時候，通過集合點使 500 個用戶進行事務并發(fā)， 能夠看出在 500 個用戶同時并發(fā)時吞吐量呈爬坡式增加，未出現(xiàn)其他異常情況，表 明目前系統(tǒng)在 500 個用戶并發(fā)處理不存在瓶頸。 結果分析： 分析：在 500 個用戶運行的情況下，系統(tǒng)的總吞吐量達到 27,800,954,406 bytes；平均每秒吞吐量 11,497,500 bytes；總點擊次數(shù) 2,132,992 次；平均每秒 點擊次數(shù) 882.131 次；vuser end transaction

15、 , vuser init transaction 是系統(tǒng) 默認的事務，actiong transaction 是錄制時進行操作的事務，我們可以看到 500 個用戶運行事務時，最短的時間為 0.465s，最長時間為 5.125s，平均時間為 3.28s，其中 90%都小于等于 4.243s，500 個用戶全部通過。 9.2并發(fā)測試并發(fā)測試 總體描述：總體描述：500500 個用戶成功加載后，分別由個用戶成功加載后，分別由 5050、100100、200200、300300 用戶做系統(tǒng)并用戶做系統(tǒng)并 發(fā)測試。發(fā)測試。 場景設計：場景設計：每秒加載 5 個用戶，持續(xù)增加在線用戶，系統(tǒng)成功加載 50

16、0 虛擬用 戶在線后，設置登錄集合點，模擬 50、100、200、300 用戶并發(fā)登錄系統(tǒng)、地圖操 作，采取多機聯(lián)合測試、集合點策略，等待登錄用戶分別達到 50、100、200、300 個用戶時候，同時提交事務，測試 500 人在線后，同時并發(fā) 50、100、200、300 個 用戶時事務的通過率和響應時間，所有用戶加載完后持續(xù)運行 3 分鐘，以每 10 秒 5 個用戶退出系統(tǒng)。不考慮 think time。 測試重點：測試重點：頁面響應時間，服務器的 cpu、內(nèi)存使用情況。 場景一：場景一：500500 個用戶成功加載后，其中個用戶成功加載后，其中 5050 個用戶做并發(fā)操作。個用戶做并發(fā)操

17、作。 場景描述：場景描述：加載 500 個用戶，其中 50 個用戶并發(fā)操作情況下，對事務響應時 間變化趨勢和服務器資源使用情況進行統(tǒng)計分析。 場景設計：場景設計：每 10 秒加載登錄 5 個用戶，持續(xù)增加在線用戶，集合點加載到 50 各用戶開始進行并發(fā)執(zhí)行事務，系統(tǒng)成功加載 500 虛擬用戶在線后，所有用戶在線 持續(xù) 3 分鐘后，以每 10 秒 5 個用戶退出系統(tǒng)。不考慮 think time。 根據(jù)如上圖得到的數(shù)據(jù)信息：action_transaction 響應時間最大值 6.302s、 最小值 0.203s、平均值 2.003s；processor time（processor_total

18、）cpu 使用率 最小值為 0%、最大值為 8.594%、平均值為 0.930%,符合 cpu 資源利用常規(guī)指標 （80%）；available mbytes (memory):物理內(nèi)存剩余最小值為 712m、最大值 996m、平均值 879.571m，符合物理內(nèi)存剩余使用量大于 10%的常規(guī)指標。 通過分析得出，此系統(tǒng)支持在設定的硬件環(huán)境下進行 50 個用戶的并發(fā)運行。 場景二：場景二：500500 個用戶成功加載后，其中個用戶成功加載后，其中 100100 個用戶做并發(fā)操作。個用戶做并發(fā)操作。 場景描述：場景描述：加載 500 個用戶，其中 100 個用戶并發(fā)操作情況下，對事務響應 時間變

19、化趨勢和服務器資源使用情況進行統(tǒng)計分析。 場景設計：場景設計：每 10 秒加載登錄 5 個用戶，持續(xù)增加在線用戶，集合點加載到 100 各用戶開始進行并發(fā)執(zhí)行事務，系統(tǒng)成功加載 500 虛擬用戶在線后，所有用戶在線 持續(xù) 3 分鐘后，以每 10 秒 5 個用戶退出系統(tǒng)。不考慮 think time。 根據(jù)如上圖得到的數(shù)據(jù)信息：action_transaction 響應時間最大值 5.024s、 最小值 0.214s、平均值 2.562s；processor time（processor_total）cpu 使用 率最小值為 5.729%、最大值為 25%、平均值為 13.051%,符合 cpu

20、 資源利用常規(guī)指標 （80%）；available mbytes (memory):物理內(nèi)存剩余最小值為 883m、最大值 984m、平均值 933.529m，符合物理內(nèi)存剩余使用量大于 10%的常規(guī)指標。 通過分析得出，此系統(tǒng)支持在設定的硬件環(huán)境下進行 100 個用戶的并發(fā)運行。 場景三：場景三：500500 個用戶成功加載后，其中個用戶成功加載后，其中 200200 個用戶做并發(fā)操作。個用戶做并發(fā)操作。 場景描述：場景描述：加載 500 個用戶，其中 200 個用戶并發(fā)操作情況下，對事務響應 時間變化趨勢和服務器資源使用情況進行統(tǒng)計分析。 場景設計：場景設計：每 10 秒加載登錄 5 個用

21、戶，持續(xù)增加在線用戶，集合點加載到 200 各用戶開始進行并發(fā)執(zhí)行事務，系統(tǒng)成功加載 500 虛擬用戶在線后，所有用戶在線 持續(xù) 3 分鐘后，以每 10 秒 5 個用戶退出系統(tǒng)。不考慮 think time。 根據(jù)如上圖得到的數(shù)據(jù)信息：action_transaction 響應時間最大值 4.258s、 最小值 0.187s、平均值 2.956s；processor time（processor_total）：cpu 使用 率最小值為 0%、最大值為 57.552%、平均值為 12.625%，符合 cpu 資源利用常規(guī)指 標（80%）；available mbytes (memory):物理內(nèi)

22、存剩余最小值為 529m、最大值 1027m、平均值 680m，符合物理內(nèi)存剩余使用量大于 10%的常規(guī)指標。 通過分析得出，此系統(tǒng)支持在設定的硬件環(huán)境下進行 200 個用戶的并發(fā)運行。 場景四：場景四：500500 個用戶成功加載后，其中個用戶成功加載后，其中 300300 個用戶做并發(fā)操作。個用戶做并發(fā)操作。 場景描述：場景描述：500 個用戶 300 個用戶的并發(fā)操作情況下，對事務響應時間變化趨 勢和服務器資源使用情況進行統(tǒng)計分析。 場景設計：場景設計：每 10 秒加載登錄 5 個用戶，持續(xù)增加在線用戶，集合點加載到 300 用戶開始進行并發(fā)執(zhí)行事務，系統(tǒng)成功加載 500 虛擬用戶在線后

23、，所有用戶在線持 續(xù) 3 分鐘后，以每 10 秒 5 個用戶退出系統(tǒng)。不考慮 think time。 根據(jù)如上圖得到的數(shù)據(jù)信息：action_transaction 響應時間最大值 5.224s、 最小值 0.187s、平均值 3.23s；processor time（processor_total）cpu 使用率最 小值為 1.042%、最大值為 79.688%、平均值為 34.466%,符合 cpu 資源利用常規(guī)指標 （80%）；available mbytes (memory):物理內(nèi)存剩余最小值為 658m、最大值 709m、平均值 683.706m，均符合物理內(nèi)存剩余使用量大于 10

24、%的常規(guī)指標。 通過分析得出，此系統(tǒng)支持在設定的硬件環(huán)境下進行 300 個用戶的并發(fā)運行。 結果分析結果分析： 交易響應時間（秒） 并發(fā)用戶數(shù) 最小平均最大 500 用戶成功加 載后 50 個用戶做并 發(fā)登錄 0.2032.0036.302 500 用戶成功加0.2032.5625.024 載后 100 個用戶做 并發(fā)登錄 500 用戶成功加 載后 200 個用戶做 并發(fā)登錄 0.187 2.9564.258 500 用戶成功加 載后 300 個用戶做 并發(fā)登錄 0.1873.235.224 1 場景執(zhí)行情況： 場景執(zhí)行圖中，500 個虛擬用戶持續(xù)并發(fā)進行系統(tǒng)登錄、地圖瀏覽過程中，事 務響應時

25、間與虛擬用戶運行情況合并，測試時間延長并未造成系統(tǒng)登錄事務響應時 間延長。 2. 硬件資源占用情況： 根據(jù)分析可見，在進行 50、100、200、300 用戶并發(fā)登錄過程中，應用服 務器平均占用率和數(shù)據(jù)庫服務器平均占率均合格。 9.3負載測試負載測試 場景描述：場景描述：加載 1000 個用戶，持續(xù)運行 30 分鐘，監(jiān)測事務響應時間變化趨勢 和服務器資源使用情況。 場景設計：場景設計：每 05 秒加載登錄 10 個用戶，持續(xù)增加在線用戶，系統(tǒng)成功加載 1000 虛擬用戶在線后，所有用戶在線持續(xù) 30 分鐘后，以每 05 秒 2 個用戶退出系統(tǒng)。 不考慮 think time。 測試重點：測試重

26、點：頁面響應時間，服務器的 cpu、內(nèi)存使用情況。 測試結果：測試結果： 服務器資源檢測如下圖： 說明：cpu 利用率最大值 13.189%，小于標準值 80%。硬盤讀取或寫入硬盤的頁數(shù)最大 值為 0.332，最小值為 0.000，符合標準范圍 0020,表明目前系統(tǒng)真實環(huán)境硬件不存在 瓶頸。 系統(tǒng)吞吐量： 說明：可以看出隨著點擊率越大，吞吐量隨之增加，未出現(xiàn)其他異常情況，平均值達 到 450904.284。 但是隨著用戶數(shù)量增大，吞吐量變化卻不大，隨意初步推斷網(wǎng)絡寬帶 有所限制。 9.4業(yè)務測試業(yè)務測試 9.4.1 空間基礎信息空間基礎信息 場景描述：場景描述：此場景測試 100 個用戶登錄

27、系統(tǒng)的運行情況。 場景設計：場景設計：每 15 秒加載登錄 2 個用戶，持續(xù)增加在線用戶，系統(tǒng)成功加載 100 虛擬用戶在線后，所有用戶在線持續(xù) 20 分鐘后，以每 15 秒 2 個用戶退出系統(tǒng)。不 考慮 think time。 測試重點：測試重點：頁面響應時間，服務器的 cpu、內(nèi)存使用情況。 測試結果：測試結果： 服務器資源監(jiān)測圖： 事務響應圖： 測試結果分析： 平均事物響應時間結果： 測試結論測試結論：頁面平均響應時間 0.001s；%processor time 小于 80%，說明 cpu 沒有瓶頸； 可用物理內(nèi)存數(shù) available mbytes 的值很?。? mb 或更?。?，則說

28、明計算機上總的內(nèi) 存可能不足，或某程序沒有釋放內(nèi)存。當前監(jiān)測值為 60829.000，系統(tǒng)不存在內(nèi)存溢出 的問題。 9.4.2 古建保護與修繕管理古建保護與修繕管理 場景描述：場景描述：此場景測試 100 個用戶登錄系統(tǒng)的運行情況。 場景設計：場景設計：每 15 秒加載登錄 2 個用戶，持續(xù)增加在線用戶，系統(tǒng)成功加載 100 虛擬用戶在線后，所有用戶在線持續(xù) 20 分鐘后，以每 15 秒 2 個用戶退出系統(tǒng)。不 考慮 think time。 測試重點：測試重點：頁面響應時間，服務器的 cpu、內(nèi)存使用情況。 測試結果：測試結果： 吞吐量監(jiān)測圖： 事務響應時間監(jiān)測圖： 資源監(jiān)測圖： 測試結果分析

29、： 平均事務響應圖： 測試結論：測試結論：頁面平均響應時間 0.001s，最大值為 0.002s，滿足當前用戶需求； %processor time 小于 80%，說明 cpu 沒有瓶頸。 9.4.3 園林景觀管理系統(tǒng)園林景觀管理系統(tǒng) 場景描述：場景描述：此場景測試 100 個用戶登錄系統(tǒng)的運行情況。 場景設計：場景設計：每 15 秒加載登錄 2 個用戶，持續(xù)增加在線用戶，系統(tǒng)成功加載 100 虛擬用戶在線后，所有用戶在線持續(xù) 10 分鐘后，以每 15 秒 2 個用戶退出系統(tǒng)。不 考慮 think time。 場景設計圖： 場景運行圖: 測試重點：測試重點：頁面響應時間，服務器的 cpu、內(nèi)存

30、使用情況。 測試結果：測試結果： 資源監(jiān)測圖： 平均事務響應圖： 吞吐量監(jiān)測圖： 測試結果分析： 測試結論：測試結論：頁面平均響應時間 0.001s，最大值為 0.003s，滿足當前用戶需求； %processor time 最大為 15.972 小于 75%80%，說明 cpu 沒有瓶頸。%privileged time：（cpu 內(nèi)核時間）是在特權模式下處理線程執(zhí)行代碼所花時間的百分比，如果 該參數(shù)值和physical disk參數(shù)值一直很高，表明 i/o 有問題?？煽紤]更換更快的 硬盤系統(tǒng)，當前監(jiān)測該值最大為 0.022，說明內(nèi)存硬盤無瓶頸。可用物理內(nèi)存數(shù) available mbytes 的值很?。? mb 或更小），則說明計算機上總的內(nèi)存可能不足， 或某程序沒有釋放內(nèi)存。當前最小值監(jiān)測為 60865.000，說明系統(tǒng)不存在內(nèi)容溢出的 問題。 9.4.4 文物管理展示文物管理展示 場景描述：場景描述：此場景測試 100 個用戶登錄系統(tǒng)的運行情況。 場景設計：場景設計：每 5 秒加載登錄 2 個用戶，持續(xù)增加在線用戶，系統(tǒng)成功加載 100 虛擬用戶在線后，所有用戶在線持續(xù) 5 分鐘后，以每 5 秒 10 個用戶退出系統(tǒng)。不 考慮 think time。 場景設計圖：