轉(zhuǎn)帖：出處未知

?

你的Web服務(wù)器和應(yīng)用到底能夠支持多少并發(fā)用戶訪問？在出現(xiàn)大量并發(fā)請求的情況下，軟件會(huì)出現(xiàn)問題嗎？這些問題靠通常的測試手段是無法解答的。本文介紹了Microsoft為這個(gè)目的而提供的免費(fèi)工具WAS及其用法。另外，本文介紹了一種Web應(yīng)用的性能優(yōu)化方法，并利用WAS測試了它的性能改善程度。　　編譯如下：　　隨著服務(wù)器端處理任務(wù)的日益復(fù)雜以及網(wǎng)站訪問量的迅速增長，服務(wù)器性能的優(yōu)化也成了非常迫切的任務(wù)。在優(yōu)化之前，最好能夠測試一下不同條件下服務(wù)器的性能表現(xiàn)。找出性能瓶頸所在是設(shè)計(jì)性能改善方案之前的一個(gè)至關(guān)緊要的步驟。 　　本文介紹Microsoft的Web Application Stress Tool（WAS，Web應(yīng)用負(fù)載測試工具）在Web服務(wù)器性能測試中的應(yīng)用（注：Stress基本含義為“重壓；壓力”等，本文稱之為“負(fù)載”）。另外，我們還將通過WAS評(píng)估一種相對(duì)簡單的網(wǎng)站性能改善方法，這種方法的基本思想是在服務(wù)器上生成靜態(tài)的HTML頁面、避免過多的數(shù)據(jù)庫調(diào)用。 　　負(fù)載測試是任何Web應(yīng)用的開發(fā)周期中一個(gè)重要的步驟。如果你在構(gòu)造一個(gè)為大量用戶服務(wù)的應(yīng)用，搞清楚你的產(chǎn)品配置能夠承受多大的負(fù)載非常重要。如果你在構(gòu)造一個(gè)小型的Intranet網(wǎng)站，測試能夠暴露出最終會(huì)導(dǎo)致服務(wù)器崩潰的內(nèi)存漏洞以及競爭情況。 　　無論是哪種情形，花些時(shí)間對(duì)應(yīng)用進(jìn)行負(fù)載測試可以獲得重要的基準(zhǔn)性能數(shù)據(jù)，為未來的代碼優(yōu)化、硬件配置以及系統(tǒng)軟件升級(jí)帶來方便。即使經(jīng)費(fèi)有限的開發(fā)組織也可以對(duì)它們的網(wǎng)站進(jìn)行負(fù)載測試，因?yàn)镸icrosoft的WAS是可以免費(fèi)下載的。WAS要求Windows NT 4.0 SP4或者更高，或者Windows 2000。為了對(duì)網(wǎng)站進(jìn)行負(fù)載測試，WAS可以通過一臺(tái)或者多臺(tái)客戶機(jī)模擬大量用戶的活動(dòng)。WAS支持身份驗(yàn)證、加密和Cookies，也能夠模擬各種瀏覽器類型和Modem速度，它的功能和性能可以與數(shù)萬美元的產(chǎn)品相媲美。如果你對(duì)WAS和Microsoft的另外一個(gè)測試工具Web Capacity Analysis Tool （WCAT）之間的差別感興趣，可以訪問Microsoft Web工具的比較頁面。 要對(duì)網(wǎng)站進(jìn)行負(fù)載測試首先必須創(chuàng)建WAS腳本模擬用戶活動(dòng)。我們可以用下面四種方法之一創(chuàng)建腳本：通過記錄瀏覽器的活動(dòng)；通過導(dǎo)入IIS日志；通過把WAS指向Web網(wǎng)站的內(nèi)容；或者手工制作。圖1所顯示的是通過記錄瀏覽器事件生成的腳本的一部分，網(wǎng)站是Microsoft的Duwamish Book Store。Duwamish是Microsoft開發(fā)的電子商務(wù)Web應(yīng)用示例，從Duwamish網(wǎng)站的“Phase 4”鏈接可以下載這個(gè)軟件包。下載包中包含了它自己的WAS測試腳本。 ??????? 【圖1】 ??????? 制作WAS腳本是相當(dāng)簡單的，不過要制作出模擬真實(shí)用戶活動(dòng)的腳本有點(diǎn)兒復(fù)雜。如果你已經(jīng)有一個(gè)運(yùn)行的Web網(wǎng)站，可以使用Web服務(wù)器的日志來確定Web網(wǎng)站上的用戶點(diǎn)擊分布。如果你的應(yīng)用還沒有開始運(yùn)行，那么只好根據(jù)經(jīng)驗(yàn)作一些猜測了。 　　圖1這個(gè)腳本中我們假定有30個(gè)會(huì)員在瀏覽書店，同時(shí)又有一個(gè)會(huì)員正在購買。要模擬兩者混合而成的行為，首先必須創(chuàng)建頁面組并在腳本的Page Group分枝確定點(diǎn)擊分布情況。在Page Group分枝中我們可以增加、修改或刪除頁面組，也可以為各個(gè)組修改流量的分布。 　　圖2顯示了grp_browse和grp_buy這兩個(gè)頁面組以及30比1的流量分布。? ??????? 【圖2】 ??????? 創(chuàng)建了頁面組之后，我們就可以在主腳本視圖中賦予各個(gè)請求不同的頁面組，如圖3所示。為每個(gè)請求指定頁面組相當(dāng)于告訴WAS如何分布流量。記住在本例中對(duì)grp_buy組頁面的請求約占總數(shù)的3%，而對(duì)grp_browse組頁面的請求約占97%。? ??????? 【圖3】 ??????? 如果需要在查詢字符串中傳遞“名字-值”對(duì)，可以用WAS的查詢字符串編輯器來定義各個(gè)變量的所有可能的值。在輸入變量值后，既可以要求WAS順序地使用變量的各個(gè)值，也可以要求WAS在請求時(shí)隨機(jī)選擇變量值。這在一定程度上增加了腳本所模擬行為的真實(shí)性，也可以幫助避免緩沖對(duì)測試結(jié)果的影響準(zhǔn)備好測試腳本之后，我們可以調(diào)整測試配置以便觀察不同條件下的應(yīng)用性能。圖4是WAS的設(shè)置界面。 ? ??????? 【圖4】 ??????? Stress Level和Stress multiplier這二個(gè)項(xiàng)決定了訪問服務(wù)器的并發(fā)連接的數(shù)量。Microsoft建議不要選擇超過100的Stress Level值。如果要模擬的并發(fā)連接數(shù)量超過100個(gè)，可以調(diào)整Stress multiplier或使用多個(gè)客戶機(jī)。在負(fù)載測試期間WAS將通過DCOM與其他客戶機(jī)協(xié)調(diào)。有關(guān)在測試中使用多個(gè)客戶機(jī)的更多信息，參見http://webtool.rte.microsoft.com/kb/hkb13.htm。 　　如果網(wǎng)站提供個(gè)性化服務(wù)，要進(jìn)行身份驗(yàn)證或使用Cookies，我們還要為WAS提供一個(gè)用戶目錄。WAS中的用戶存儲(chǔ)了發(fā)送給服務(wù)器的密碼以及服務(wù)器發(fā)送給客戶端的Cookies。增加用戶數(shù)量并不增加Web服務(wù)器的負(fù)載。必須提供足夠數(shù)量的用戶以滿足并發(fā)連接的要求（Stesss Level乘以Stress Multiplier）。有關(guān)線程、用戶、Cookies相互作用的更多信息請參見http://webtool.rte.microsoft.com/Threads/WASThreads.htm。 　　WAS允許設(shè)置warmup（熱身）時(shí)間，一般可以設(shè)置為1分鐘。在warmup期間WAS開始執(zhí)行腳本，但不收集統(tǒng)計(jì)數(shù)據(jù)。warmup時(shí)間給MTS、數(shù)據(jù)庫以及磁盤緩沖等一個(gè)機(jī)會(huì)來做準(zhǔn)備工作。如果在warmup時(shí)間內(nèi)收集統(tǒng)計(jì)數(shù)據(jù)，這些操作的開銷將影響性能測試結(jié)果。 　　設(shè)置頁面提供的另外一個(gè)有用的功能是限制帶寬（throttle bandwidth）。帶寬限制功能能夠?yàn)闇y試模擬出Modem（14.k K，28.8 K，56 K）、ISDN（64 K，128 K）以及T1（1.54 M）的速度。使用帶寬限制功能可以精確地預(yù)測出客戶通過撥號(hào)網(wǎng)絡(luò)或其他外部連接訪問Web服務(wù)器所感受的性能。 　　要理解這些不同的設(shè)置對(duì)應(yīng)用的影響，有必要了解如何使用WAS收集性能數(shù)據(jù)。 使用WAS，從遠(yuǎn)程Windows NT和Windows 2000機(jī)器獲取和分析性能計(jì)數(shù)器（Performance Counter）是很方便的。加入計(jì)數(shù)器要用到圖5所示的Perf Counters分枝。 ??????? 【圖5】 ??????? 在測試中選擇哪些計(jì)數(shù)器顯然跟測試目的有關(guān)。雖然下面這個(gè)清單不可能精確地隔離出性能瓶頸所在，但對(duì)一般的Web服務(wù)器性能測試來說卻是一個(gè)好的開始。 ??????? · 處理器：CPU使用百分比（% CPU Utilization） ??????? · 線程：每秒的上下文切換次數(shù)（Context Switches Per Second (Total)） ??????? · ASP：每秒請求數(shù)量（Requests Per Second） ??????? · ASP：請求執(zhí)行時(shí)間（Request Execution Time） ??????? · ASP：請求等待時(shí)間（Request Wait Time） ??????? · ASP：置入隊(duì)列的請求數(shù)量（Requests Queued） 　　CPU使用百分比反映了處理器開銷。CPU使用百分比持續(xù)地超過75%是性能瓶頸在于處理器的一個(gè)明顯的跡象。每秒上下文切換次數(shù)指示了處理器的工作效率。如果處理器陷于每秒數(shù)千次的上下文切換，說明它忙于切換線程而不是處理ASP腳本。 　　每秒的ASP請求數(shù)量、執(zhí)行時(shí)間以及等待時(shí)間在各種測試情形下都是非常重要的監(jiān)測項(xiàng)目。每秒的請求數(shù)量告訴我們每秒內(nèi)服務(wù)器成功處理的ASP請求數(shù)量。執(zhí)行時(shí)間和等待時(shí)間之和顯示了反應(yīng)時(shí)間，這是服務(wù)器用處理好的頁面作應(yīng)答所需要的時(shí)間。 　　我們可以繪出隨著測試中并發(fā)用戶數(shù)量的增加每秒請求數(shù)量和反應(yīng)時(shí)間的變化圖。增加并發(fā)用戶數(shù)量時(shí)每秒請求數(shù)量也會(huì)增加。然而，我們最終會(huì)達(dá)到這樣一個(gè)點(diǎn)，此時(shí)并發(fā)用戶數(shù)量開始“壓倒”服務(wù)器。如果繼續(xù)增加并發(fā)用戶數(shù)量，每秒請求數(shù)量開始下降，而反應(yīng)時(shí)間則會(huì)增加。要搞清楚硬件和軟件的能力，找出這個(gè)并發(fā)用戶數(shù)量開始“壓倒”服務(wù)器的臨界點(diǎn)非常重要。 　　置入隊(duì)列的ASP請求數(shù)量也是一個(gè)重要的指標(biāo)。如果在測試中這個(gè)數(shù)量有波動(dòng)，某個(gè)COM對(duì)象所接收到的請求數(shù)量超過了它的處理能力。這可能是因?yàn)樵趹?yīng)用的中間層使用了一個(gè)低效率的組件，或者在ASP會(huì)話對(duì)象中存儲(chǔ)了一個(gè)單線程的單元組件。 　　運(yùn)行WAS的客戶機(jī)CPU使用率也有必要監(jiān)視。如果這些機(jī)器上的CPU使用率持續(xù)地超過75%，說明客戶機(jī)沒有足夠的資源來正確地運(yùn)行測試，此時(shí)應(yīng)該認(rèn)為測試結(jié)果不可信。在這種情況下，測試客戶機(jī)的數(shù)量必須增加，或者減小測試的Stress Level。 每次測試運(yùn)行結(jié)束后WAS會(huì)生成詳細(xì)的報(bào)表，即使測試被提前停止也一樣。WAS報(bào)表可以從View菜單選擇Reports查看。下面介紹一下報(bào)表中幾個(gè)重要的部分。 　　如果這是一個(gè)新創(chuàng)建的測試腳本，你應(yīng)該檢查一下報(bào)表的Result Codes部分。這部分內(nèi)容包含了請求結(jié)果代碼、說明以及服務(wù)器返回的結(jié)果代碼的數(shù)量。如果這里出現(xiàn)了404代碼（頁面沒有找到），說明在腳本中有錯(cuò)誤的頁面請求。 　　頁面摘要部分提供了頁面的名字，接收到第一個(gè)字節(jié)的平均時(shí)間（TTFB），接收到最后一個(gè)字節(jié)的平均時(shí)間（TTLB），以及測試腳本中各個(gè)頁面的命中次數(shù)。TTFB和TTLB這兩個(gè)值對(duì)于計(jì)算客戶端所看到的服務(wù)器性能具有重要意義。TTFB反映了從發(fā)出頁面請求到接收到應(yīng)答數(shù)據(jù)第一個(gè)字節(jié)的時(shí)間總和（以毫秒計(jì)），TTLB包含了TTFB，它是客戶機(jī)接收到頁面最后一個(gè)字節(jié)所需要的累計(jì)時(shí)間。 　　報(bào)表中還包含了所有性能計(jì)數(shù)器的信息。這些數(shù)據(jù)顯示了運(yùn)行時(shí)各個(gè)項(xiàng)目的測量值，同時(shí)還提供了最大值、最小值、平均值等。報(bào)表實(shí)際提供的信息遠(yuǎn)遠(yuǎn)超過了我們這里能夠介紹的內(nèi)容。為了給你一個(gè)有關(guān)表所提供信息種類的印象，圖6摘錄了一個(gè)報(bào)表實(shí)例。 　　? ??????? 【圖6】 ??????? 隨著Internet應(yīng)用的日益廣泛，用戶的要求和期望也在不斷地發(fā)展。今天的客戶期待個(gè)性化的可定制的方案，期待這些方案不僅簡單，而且快速、可靠、成本低廉。對(duì)于能夠適應(yīng)用戶需求不斷變動(dòng)的可定制頁面來說，靜態(tài)HTML已經(jīng)退出了舞臺(tái)，比如內(nèi)容根據(jù)客戶請求變化的頁面就是其中一例。這一切都要求系統(tǒng)保存相關(guān)的數(shù)據(jù)，例如有關(guān)用戶本身以及用戶可能請求哪些信息的數(shù)據(jù)。 　　緊跟這些趨勢的Web開發(fā)者已經(jīng)開始提供可定制的Web網(wǎng)站。象搜索數(shù)據(jù)之類的任務(wù)現(xiàn)在可以由服務(wù)器執(zhí)行而無需客戶干預(yù)。然而，這些變革也導(dǎo)致了一個(gè)結(jié)果，這就是許多網(wǎng)站都在使用大量的未經(jīng)優(yōu)化的數(shù)據(jù)庫調(diào)用，從而使得應(yīng)用性能大打折扣。 　　我們可以使用以下幾種方法來解決這些問題： ??????? 1. 優(yōu)化ASP代碼。 ??????? 2. 優(yōu)化數(shù)據(jù)庫調(diào)用。 ??????? 3. 使用存儲(chǔ)過程。 ??????? 4. 調(diào)整服務(wù)器性能。 　　優(yōu)秀的網(wǎng)站設(shè)計(jì)都會(huì)關(guān)注這些問題。然而，與靜態(tài)頁面的速度相比，任何數(shù)據(jù)庫調(diào)用都會(huì)顯著地影響Web網(wǎng)站的響應(yīng)速度，這主要是因?yàn)樵诎l(fā)送頁面之前必須單獨(dú)地為每個(gè)訪問網(wǎng)站的用戶進(jìn)行數(shù)據(jù)庫調(diào)用。 　　這里提出的性能優(yōu)化方案正是基于以下事實(shí)：訪問靜態(tài)HTML頁面要比訪問那些內(nèi)容依賴于數(shù)據(jù)庫調(diào)用的頁面要快。它的基本思想是：在用戶訪問頁面之前，預(yù)先從數(shù)據(jù)庫提取信息寫入存儲(chǔ)在服務(wù)器上的靜態(tài)HTML頁面。為了保證這些靜態(tài)頁面能夠及時(shí)地反映不斷變化的數(shù)據(jù)庫數(shù)據(jù)，必須有一個(gè)調(diào)度程序管理靜態(tài)頁面的生成。 　　當(dāng)然，這種方案并不能夠適應(yīng)所有的情形。例如，如果是從持續(xù)變化的大容量數(shù)據(jù)庫提取少量信息，這種方案是不合適的。不過可以適用該方案的場合還是很多。 為了保證能夠在合適的時(shí)間更新靜態(tài)HTML頁面，把下面的代碼加入到相應(yīng)的ASP頁面前面：隨著Internet應(yīng)用的日益廣泛，用戶的要求和期望也在不斷地發(fā)展。今天的客戶期待個(gè)性化的可定制的方案，期待這些方案不僅簡單，而且快速、可靠、成本低廉。對(duì)于能夠適應(yīng)用戶需求不斷變動(dòng)的可定制頁面來說，靜態(tài)HTML已經(jīng)退出了舞臺(tái)，比如內(nèi)容根據(jù)客戶請求變化的頁面就是其中一例。這一切都要求系統(tǒng)保存相關(guān)的數(shù)據(jù)，例如有關(guān)用戶本身以及用戶可能請求哪些信息的數(shù)據(jù)。 　　緊跟這些趨勢的Web開發(fā)者已經(jīng)開始提供可定制的Web網(wǎng)站。象搜索數(shù)據(jù)之類的任務(wù)現(xiàn)在可以由服務(wù)器執(zhí)行而無需客戶干預(yù)。然而，這些變革也導(dǎo)致了一個(gè)結(jié)果，這就是許多網(wǎng)站都在使用大量的未經(jīng)優(yōu)化的數(shù)據(jù)庫調(diào)用，從而使得應(yīng)用性能大打折扣。 　　我們可以使用以下幾種方法來解決這些問題： ??????? 1. 優(yōu)化ASP代碼。 ??????? 2. 優(yōu)化數(shù)據(jù)庫調(diào)用。 ??????? 3. 使用存儲(chǔ)過程。 ??????? 4. 調(diào)整服務(wù)器性能。 　　優(yōu)秀的網(wǎng)站設(shè)計(jì)都會(huì)關(guān)注這些問題。然而，與靜態(tài)頁面的速度相比，任何數(shù)據(jù)庫調(diào)用都會(huì)顯著地影響Web網(wǎng)站的響應(yīng)速度，這主要是因?yàn)樵诎l(fā)送頁面之前必須單獨(dú)地為每個(gè)訪問網(wǎng)站的用戶進(jìn)行數(shù)據(jù)庫調(diào)用。 　　這里提出的性能優(yōu)化方案正是基于以下事實(shí)：訪問靜態(tài)HTML頁面要比訪問那些內(nèi)容依賴于數(shù)據(jù)庫調(diào)用的頁面要快。它的基本思想是：在用戶訪問頁面之前，預(yù)先從數(shù)據(jù)庫提取信息寫入存儲(chǔ)在服務(wù)器上的靜態(tài)HTML頁面。為了保證這些靜態(tài)頁面能夠及時(shí)地反映不斷變化的數(shù)據(jù)庫數(shù)據(jù)，必須有一個(gè)調(diào)度程序管理靜態(tài)頁面的生成。 　　當(dāng)然，這種方案并不能夠適應(yīng)所有的情形。例如，如果是從持續(xù)變化的大容量數(shù)據(jù)庫提取少量信息，這種方案是不合適的。不過可以適用該方案的場合還是很多。 為了保證能夠在合適的時(shí)間更新靜態(tài)HTML頁面，把下面的代碼加入到相應(yīng)的ASP頁面前面： 　

??????? 每當(dāng)該頁面被調(diào)用，腳本就會(huì)提取最后的更新時(shí)間并將它與當(dāng)前時(shí)間比較。如果兩個(gè)時(shí)間之間的差值大于預(yù)定的數(shù)值，Update.asp腳本就會(huì)運(yùn)行；否則，該ASP頁面把余下的HTML代碼發(fā)送給瀏覽器。 　　最后更新時(shí)間從Application變量得到，它的第一次初始化由global.asa完成。具體的更新時(shí)間間隔應(yīng)根據(jù)頁面內(nèi)容的更新要求調(diào)整。 　　如果每次訪問ASP頁面的時(shí)候都要提供最新的信息，或者輸出與用戶輸入密切相關(guān)，這種方法并不實(shí)用，但這種方法可以適應(yīng)以固定的時(shí)間間隔更新信息的場合。 　　如果數(shù)據(jù)庫內(nèi)容由客戶通過適當(dāng)?shù)腁SP頁面更新，要確保靜態(tài)頁面也能夠自動(dòng)反映數(shù)據(jù)的變化，我們可以在ASP頁面中調(diào)用Update腳本。這樣，每當(dāng)數(shù)據(jù)庫內(nèi)容改變時(shí)服務(wù)器上也有了最新的靜態(tài)HTML頁面。 另一種處理頻繁變動(dòng)數(shù)據(jù)的辦法是借助Microsft SQL Server 7.0的Web助手向?qū)?#xff08;Web Assistant Wizard），這個(gè)向?qū)軌蚶肨ransact-SQL、存儲(chǔ)過程等從SQL Server數(shù)據(jù)生成標(biāo)準(zhǔn)的HTML文件。 　　利用SQL Server任務(wù)，Web助手向?qū)軌蛴脕矶ㄆ诘厣蒆TML頁面。正如前面概要介紹的方案， Web助手可以通過觸發(fā)子更新HTML頁面，比如在指定的時(shí)間執(zhí)行更新或者在數(shù)據(jù)庫數(shù)據(jù)變化時(shí)執(zhí)行更新。 　　SQL Server使用名為sp_makewebtask的存儲(chǔ)過程創(chuàng)建HTML頁面，它的參數(shù)是目標(biāo)HTML文件的名字和待執(zhí)行存儲(chǔ)過程的名字，查詢的輸出發(fā)送到HTML頁面。另外，也可以選擇使用可供結(jié)果數(shù)據(jù)插入的模板文件。 從前面的代碼可以看出，當(dāng)ASP頁面HtmlMain.asp需要更新時(shí)，控制以ASP文件的物理路徑為參數(shù)轉(zhuǎn)到了Update頁面。Update腳本的任務(wù)是用新的HTML數(shù)據(jù)刷新發(fā)出調(diào)用的ASP文件，并把調(diào)度ASP代碼加入到文件的開頭。為此，Update腳本打開調(diào)度模板文件，拷貝調(diào)度ASP代碼，然后控制轉(zhuǎn)到了另一部分腳本，這部分腳本主要任務(wù)是執(zhí)行數(shù)據(jù)庫操作。Update用路徑參數(shù)以寫模式打開HtmlMain.asp文件，數(shù)據(jù)庫操作的輸出以HTML格式寫入這個(gè)文件。 　　萬一用戶訪問頁面的時(shí)候正好在執(zhí)行更新，我們可以利用鎖或者其他類似的機(jī)制把頁面延遲幾秒鐘。 HtmlMain.asp（純HTML加調(diào)度ASP代碼）和main.asp（普通的ASP文件）在WAS下進(jìn)行了性能測試。main.asp文件要查找5個(gè)不同的表為頁面提取數(shù)據(jù)。為了和這兩個(gè)文件相比較，一個(gè)只訪問單個(gè)表的ASP頁面（SingleTableTest.asp）和一個(gè)純HTML文件（PlainHtml.html）也進(jìn)行了測試。 　　 測試結(jié)果如下表所示：