使用microsoftwebapplicationstresstool對web進行壓力測試(編輯修改稿)
2025-04-20 07:05 本頁面
【文章內(nèi)容簡介】 it Time） ASP：置入隊列的請求數(shù)量（Requests Queued） CPU使用百分比反映了處理器開銷。CPU使用百分比持續(xù)地超過75%是性能瓶頸在于處理器的一個明顯的跡象。每秒上下文切換次數(shù)指示了處理器的工作效率。如果處理器陷于每秒數(shù)千次的上下文切換，說明它忙于切換線程而不是處理ASP腳本。 每秒的ASP請求數(shù)量、執(zhí)行時間以及等待時間在各種測試情形下都是非常重要的監(jiān)測項目。每秒的請求數(shù)量告訴我們每秒內(nèi)服務器成功處理的ASP請求數(shù)量。執(zhí)行時間和等待時間之和顯示了反應時間，這是服務器用處理好的頁面作應答所需要的時間。 我們可以繪出隨著測試中并發(fā)用戶數(shù)量的增加每秒請求數(shù)量和反應時間的變化圖。增加并發(fā)用戶數(shù)量時每秒請求數(shù)量也會增加。然而，我們最終會達到這樣一個 點，此時并發(fā)用戶數(shù)量開始“壓倒”服務器。如果繼續(xù)增加并發(fā)用戶數(shù)量，每秒請求數(shù)量開始下降，而反應時間則會增加。要搞清楚硬件和軟件的能力，找出這個并 發(fā)用戶數(shù)量開始“壓倒”服務器的臨界點非常重要。 置入隊列的ASP請求數(shù)量也是一個重要的指標。如果在測試中這個數(shù)量有波動，某個COM對象所接收到的請求數(shù)量超過了它的處理能力。這可能是因為在應用的中間層使用了一個低效率的組件，或者在ASP會話對象中存儲了一個單線程的單元組件。 運行WAS的客戶機CPU使用率也有必要監(jiān)視。如果這些機器上的CPU使用率持續(xù)地超過75%，說明客戶機沒有足夠的資源來正確地運行測試，此時應該認為測試結(jié)果不可信。在這種情況下，測試客戶機的數(shù)量必須增加，或者減小測試的Stress Level。 本文來自無涯教程網(wǎng):每次測試運行結(jié)束后WAS會生成詳細的報表，即使測試被提前停止也一樣。WAS報表可以從View菜單選擇Reports查看。下面介紹一下報表中幾個重要的部分。 如果這是一個新創(chuàng)建的測試腳本，你應該檢查一下報表的Result Codes部分。這部分內(nèi)容包含了請求結(jié)果代碼、說明以及服務器返回的結(jié)果代碼的數(shù)量。如果這里出現(xiàn)了404代碼（頁面沒有找到），說明在腳本中有錯誤的頁面請求。 頁面摘要部分提供了頁面的名字，接收到第一個字節(jié)的平均時間（TTFB），接收到最后一個字節(jié)的平均時間（TTLB），以及測試腳本中各個頁面的命中次 數(shù)。TTFB和TTLB這兩個值對于計算客戶端所看到的服務器性能具有重要意義。TTFB反映了從發(fā)出頁面請求到接收到應答數(shù)據(jù)第一個字節(jié)的時間總和（以 毫秒計），TTLB包含了TTFB，它是客戶機接收到頁面最后一個字節(jié)所需要的累計時間。 報表中還包含了所有性能計數(shù)器的信息。這些數(shù)據(jù)顯示了運行時各個項目的測量值，同時還提供了最大值、最小值、平均值等。報表實際提供的信息遠遠超過了我們這里能夠介紹的內(nèi)容。為了給你一個有關(guān)表所提供信息種類的印象，圖6摘錄了一個報表實例。【圖6】 隨著Internet應用的日益廣泛，用戶的要求和期望也在不斷地發(fā)展。今天的客戶期待個性化的可定制的方案，期待這些方案不僅簡單，而且快速、可靠、成 本低廉。對于能夠適應用戶需求不斷變動的可定制頁面來說，靜態(tài)HTML已經(jīng)退出了舞臺，比如內(nèi)容根據(jù)客戶請求變化的頁面就是其中一例。這一切都要求系統(tǒng)保 存相關(guān)的數(shù)據(jù)，例如有關(guān)用戶本身以及用戶可能請求哪些信息的數(shù)據(jù)。 緊跟這些趨勢的Web開發(fā)者已經(jīng)開始提供可定制的Web網(wǎng)站。象搜索數(shù)據(jù)之類的任務現(xiàn)在可以由服務器執(zhí)行而無需客戶干預。然而，這些變革也導致了一個結(jié)果，這就是許多網(wǎng)站都在使用大量的未經(jīng)優(yōu)化的數(shù)據(jù)庫調(diào)用，從而使得應用性能大打折扣。 我們可以使用以下幾種方法來解決這些問題： 1. 優(yōu)化ASP代碼。
高考資料相關(guān)推薦
鄂ICP備17016276號-1