使用WAS對Web應(yīng)用程序壓力測試解析

1、精選優(yōu)質(zhì)文檔-傾情為你奉上使用WAS對Web應(yīng)用程序壓力測試WAS(Microsoft Web Application Stress Tool,Web應(yīng)用負(fù)載測試工具提供了一種簡單的方法模擬大量用戶來訪問你的網(wǎng)站。這個工具能告訴我們你的Web應(yīng)用程序工作時對硬件和軟件的使用情況。在本文中我將告訴大家如何使用WAS,以及如何理解WAS測試的數(shù)據(jù)。1 壓力測試的必要性隨著服務(wù)器端處理任務(wù)的日益復(fù)雜以及網(wǎng)站訪問量的迅速增長,服務(wù)器性能的優(yōu)化也成了非常迫切的任務(wù)。在優(yōu)化之前,最好能夠測試一下不同條件下服務(wù)器的性能表現(xiàn)。找出性能瓶頸所在是設(shè)計性能改善方案之前的一個至關(guān)緊要的步驟。負(fù)載測試是任何Web應(yīng)用

2、的開發(fā)周期中一個重要的步驟。如果你在構(gòu)造一個為大量用戶服務(wù)的應(yīng)用,搞清楚你的產(chǎn)品配置能夠承受多大的負(fù)載非常重要。如果你在構(gòu)造一個小型的Intranet網(wǎng)站,測試能夠暴露出最終會導(dǎo)致服務(wù)器崩潰的內(nèi)存漏洞以及競爭情況。但是在實際的開發(fā)過程中,要按照實際投入運行的情況,組織成千上萬的用戶來進(jìn)行壓力測試,無論從那個方面看,都是不現(xiàn)實的。而且這樣一旦發(fā)現(xiàn)了問題,不僅需要重復(fù)的進(jìn)行這種耗費巨大的測試,而且問題不容易重現(xiàn),不能方便的找出性能的瓶頸所在。而使用軟件進(jìn)行壓力測試就不會存在這種情況。無論是哪種情形,花些時間對應(yīng)用進(jìn)行負(fù)載測試可以獲得重要的基準(zhǔn)性能數(shù)據(jù),為未來的代碼優(yōu)化、硬件配置以及系統(tǒng)軟件升級帶來

3、方便。即使經(jīng)費有限的開發(fā)組織也可以對它們的網(wǎng)站進(jìn)行負(fù)載測試,因為Microsoft的壓力測試工具WAS是可以免費下載的。2 WAS概要介紹為了有效的對Web應(yīng)用程序進(jìn)行壓力測試,Microsoft發(fā)布了這個簡單易用,功能強(qiáng)大的工具WAS。WAS要求Windows NT 4.0 SP4或者更高,或者Windows 2000。為了對網(wǎng)站進(jìn)行負(fù)載測試, WAS可以通過一臺或者多臺客戶機(jī)模擬大量用戶的活動。WAS支持身份驗證、加密和Cookies,也能夠模擬各種瀏覽器類型和Modem速度,它的功能和性能可以與數(shù)萬美元的產(chǎn)品相媲美。使用WAS時,為了更加接近真實的進(jìn)行壓力測試,我們推薦運行WAS的測試機(jī)

4、和Web Server分開。3 開始使用WAS要對網(wǎng)站進(jìn)行負(fù)載測試首先必須創(chuàng)建WAS腳本模擬用戶活動。我們可以用下面四種方法之一創(chuàng)建腳本:l通過記錄瀏覽器的活動l通過導(dǎo)入IIS日志l通過把WAS指向Web網(wǎng)站的內(nèi)容l手工制作在這里我們拿最常用的方法通過記錄瀏覽器的活動來講解。其他三種方法在后面將會提到。3.1 錄制測試腳本打開菜單,選擇Scripts|Create|Record 創(chuàng)建一個測試腳本 選取要記錄的內(nèi)容,有下面3種 l Record delay between request:記錄了請求之間的延遲。由于用戶實際上在瀏覽網(wǎng)站時,請求之間存在幾秒甚至幾分鐘的延遲,這種錄制方法在執(zhí)行時會模

5、仿用戶之間的延遲發(fā)送請求,所以會是一個更加實際的測試。如果我們的目的是要發(fā)現(xiàn)Web應(yīng)用程序的承受極限,就不要選擇該項;如果只是想模擬一個特定數(shù)量的用戶場景,那么選擇該項進(jìn)行測試捕捉請求延遲。l Record browser cookies & Record the host header:只記錄用戶的會話,不記錄延遲時間。一般情況下,我們不需要選擇這兩項,可以讓W(xué)AS創(chuàng)建cookies和host header,就好像用戶登陸你的網(wǎng)站一樣。然而,如果你有網(wǎng)站的回歸信息時(比如一個用戶的主要特征信息或者與一個永久性cookies 相連的其他信息,在模擬一個新的用戶登陸網(wǎng)站和進(jìn)行必要的用戶配

6、置測試前,必須保證清除cookies,如果Web應(yīng)用程序需要用戶接受cookies,那么需要選中該選項。目前這個版本的WAS軟件對基于瀏覽器IE錄制腳本的方式還不支持HTTP/SSL請求。一般情況下,只選擇后二種會增加壓力的強(qiáng)度。根據(jù)壓力測試實際的情況,選擇合適的選項,然后點“Next | Finish”,WAS會打開一個IE窗口,在IE中輸入要測試的站點地址,然后我們就可以按照實際的情況開始瀏覽站點了,瀏覽的同時也就是執(zhí)行測試用例的過程。 等測試用例執(zhí)行完成后,切換到WAS窗口,點“Stop Recording:”按鈕,停止錄制腳本 WAS回到了視圖頁面,在該頁面中你可以看到在錄制過程中WA

7、S收集的每一個鏈接,而且還可以編輯GET、POST以及HEAD信息。 制作WAS腳本是相當(dāng)簡單的,不過要制作出模擬真實用戶活動的腳本有點兒復(fù)雜。如果你已經(jīng)有一個運行的Web網(wǎng)站,可以使用Web服務(wù)器的日志來確定Web網(wǎng)站上的用戶點擊分布。如果你的應(yīng)用還沒有開始運行,那么只好根據(jù)經(jīng)驗作一些猜測了。3.2 負(fù)載參數(shù)設(shè)置測試腳本錄制完成后,下一步我們要作的就是配置運行腳本的負(fù)載選項,我們可以調(diào)整測試配置以便觀察不同條件下的應(yīng)用性能。3.2.1 Content Tree由于我們的WAS和Web Server是分開的,所以這里我們不需要設(shè)置3.2.2 Setting(設(shè)置我們只要點擊“Setting”就

8、開始負(fù)載選項設(shè)置。 1.ConCurrent Connections:Stress Level(threads的數(shù)值決定了所有客戶機(jī)創(chuàng)建的Windows的線程的數(shù)值。每一個線程創(chuàng)建多個Socket連接(具體多少Socket連接數(shù)取決于Stress multiplier (sockets per thread,每個Socket 連接就是一個并發(fā)的請求(request。下面這個公式表示了它們之間的關(guān)系:總的并發(fā)請求數(shù) = Stress Level * Stress multiplier = 總的Socket連接數(shù)Stress Level和Stress multiplier這二個項決定了訪問服務(wù)器的

9、并發(fā)連接的數(shù)量。Microsoft建議不要選擇超過100的Stress Level值。如果要模擬的并發(fā)連接數(shù)量超過100個,可以調(diào)整Stress multiplier或使用多個客戶機(jī)。在負(fù)載測試期間WAS將通過DCOM與其他客戶機(jī)協(xié)調(diào)。2.Test Run Time:設(shè)定持續(xù)運行多長時間的測試。我們可以在這里設(shè)定讓W(xué)AS持續(xù)運行多少天、多少個小時、多少分鐘、多少秒3.Request Delay(in milliseconds:設(shè)定請求延遲時間的最大、最小值,當(dāng)然我們也可以選擇“Use random delay”使用隨機(jī)的延遲時間。一般情況下,我們常常會瀏覽一頁,發(fā)現(xiàn)一個鏈接后,我們點擊它。即便

10、對該網(wǎng)站熟悉的人,4.Suspend:WAS允許設(shè)置warmup(熱身時間,一般可以設(shè)置為1分鐘。在warmup期間WAS開始執(zhí)行腳本,但不收集統(tǒng)計數(shù)據(jù)。warmup時間給MTS、數(shù)據(jù)庫以及磁盤緩沖等一個機(jī)會來做準(zhǔn)備工作。如果在warmup時間內(nèi)收集統(tǒng)計數(shù)據(jù),這些操作的開銷將影響性能測試結(jié)果。WAS 也允許設(shè)置CoolDown時間。在WAS執(zhí)行的時間達(dá)到設(shè)定的Test Run Time時,進(jìn)入CoolDown Time,這時WAS并沒有停止執(zhí)行腳本,同樣也不會收集統(tǒng)計數(shù)據(jù)。下圖表示了它們的先后關(guān)系。WarmUp不收集統(tǒng)計數(shù)據(jù)Test Run Time收集統(tǒng)計數(shù)據(jù)CoolDown不收集統(tǒng)計數(shù)據(jù)5

11、.Bandwith:設(shè)置頁面提供的另外一個有用的功能是限制帶寬(throttle bandwidth。帶寬限制功能能夠為測試模擬出Modem(14.k K,28.8 K,56 K、ISDN(64 K,128 K以及T1(1.54 M的速度。使用帶寬限制功能可以精確地預(yù)測出客戶通過撥號網(wǎng)絡(luò)或其他外部連接訪問Web服務(wù)器所感受的性能。6.Redirects、Throughput、Name resolution:這幾個選項一般情況下采用默認(rèn)情況即可。選中Follow HTTP redirects選項將會支持重定向。選中Throughput中的兩項,WAS將會收集活動用戶的cookies,以及收集網(wǎng)站

12、的統(tǒng)計數(shù)字。默認(rèn)情況下都會選中這兩項,如果不選擇,將會增加壓力測試的強(qiáng)度。Name resolution默認(rèn)情況下沒有選中。選中該選項,會讓每一個客戶測試機(jī)執(zhí)行查詢,只有在使用多個子網(wǎng)時才需要選中該項。(幫助原文:have each individual test client perform a lookup,this is useful when using multiple subnets3.2.3 Perf Counters(性能計數(shù)器使用WAS,從遠(yuǎn)程Windows NT和Windows 2000機(jī)器獲取和分析性能計數(shù)器(Performance Counter是很方便的。加入計數(shù)器要

13、用到下圖所示的Perf Counters分枝。 一般情況下,這里需要添加的性能計數(shù)器有:1 Web Server:·處理器:CPU使用百分比(% CPU Utilization·內(nèi)存:內(nèi)存使用百分比(% Memory Utilization·線程:每秒的上下文切換次數(shù)(Context Switches Per Second (Total·ASP:每秒請求數(shù)量(Requests Per Second·ASP:請求執(zhí)行時間(Request Execution Time·ASP:請求等待時間(Request Wait Time·A

14、SP:置入隊列的請求數(shù)量(Requests Queued2 各個WAS測試機(jī)·處理器:CPU使用百分比(% CPU Utilization·內(nèi)存:內(nèi)存使用百分比(% Memory Utilization在測試中選擇哪些計數(shù)器顯然跟測試目的有關(guān)。雖然下面這個清單不可能精確地隔離出性能瓶頸所在,但對一般的Web服務(wù)器性能測試來說卻是一個好的開始。處理器:CPU使用百分比(% CPU Utilization線程:每秒的上下文切換次數(shù)(Context Switches Per Second (TotalASP:每秒請求數(shù)量(Requests Per SecondASP:請求執(zhí)行時間

15、(Request Execution TimeASP:請求等待時間(Request Wait TimeASP:置入隊列的請求數(shù)量(Requests QueuedCPU使用百分比反映了處理器開銷。CPU使用百分比持續(xù)地超過75%是性能瓶頸在于處理器的一個明顯的跡象。每秒上下文切換次數(shù)指示了處理器的工作效率。如果處理器陷于每秒數(shù)千次的上下文切換,說明它忙于切換線程而不是處理ASP腳本。每秒的ASP請求數(shù)量、執(zhí)行時間以及等待時間在各種測試情形下都是非常重要的監(jiān)測項目。每秒的請求數(shù)量告訴我們每秒內(nèi)服務(wù)器成功處理的ASP請求數(shù)量。執(zhí)行時間和等待時間之和顯示了反應(yīng)時間,這是服務(wù)器用處理好的頁面作應(yīng)答所需要

16、的時間。我們可以繪出隨著測試中并發(fā)用戶數(shù)量的增加每秒請求數(shù)量和反應(yīng)時間的變化圖。增加并發(fā)用戶數(shù)量時每秒請求數(shù)量也會增加。然而,我們最終會達(dá)到這樣一個點,此時并發(fā)用戶數(shù)量開始“壓倒”服務(wù)器。如果繼續(xù)增加并發(fā)用戶數(shù)量,每秒請求數(shù)量開始下降,而反應(yīng)時間則會增加。要搞清楚硬件和軟件的能力,找出這個并發(fā)用戶數(shù)量開始“壓倒”服務(wù)器的臨界點非常重要。置入隊列的ASP請求數(shù)量也是一個重要的指標(biāo)。如果在測試中這個數(shù)量有波動,某個COM對象所接收到的請求數(shù)量超過了它的處理能力。這可能是因為在應(yīng)用的中間層使用了一個低效率的組件,或者在ASP會話對象中存儲了一個單線程的單元組件。運行WAS的客戶機(jī)CPU使用率也有必要

17、監(jiān)視。如果這些機(jī)器上的CPU使用率持續(xù)地超過75%,說明客戶機(jī)沒有足夠的資源來正確地運行測試,此時應(yīng)該認(rèn)為測試結(jié)果不可信。在這種情況下,測試客戶機(jī)的數(shù)量必須增加,或者減小測試的Stress Level。3.2.4 Page Groups對于一個Web應(yīng)用而言,同一時刻用戶點擊分布是不一樣的。WAS允許設(shè)置用戶點擊流量的分布比例。 這里我們假設(shè)在一個Web應(yīng)用程序中,有650個人同時在線,其中100人正在添加提交數(shù)據(jù),占15.38%;有150人正在查詢,占23.08%。按照不同的Web應(yīng)用,我們可以根據(jù)實際的情況在定制這個比例關(guān)系,來更加符合實際的情況。3.2.5 Users現(xiàn)在很多Web應(yīng)用程

18、序為了提供個性化的服務(wù),都設(shè)計了登陸過程。每個用戶都有自己的登陸名和密碼。WAS也考慮到了這種情況,我們只要在Users分支中添加用戶名和對應(yīng)的密碼即可。 3.2.6 Clients添加多個WAS客戶機(jī)。在運行期間,各個WAS客戶機(jī)是通過DCOM來協(xié)調(diào)的。各個WAS客戶機(jī)只要正確安裝了WAS軟件,啟動了WebTool服務(wù),它們就可以自己協(xié)調(diào)操作。我們只要在Clients分支內(nèi)添加WAS客戶機(jī)即可。 3.2.7 Cookies這里顯示的是用戶名以及對應(yīng)的cookies。這里不需要設(shè)置。4 運行測試腳本所有的設(shè)置完成以后,我們就可以運行WAS來進(jìn)行壓力測試了。要運行測試腳本很簡單,只要選中測試腳本

19、的名稱,然后點工具欄上的“運行”按鈕,即可。建議:第一次運行測試腳本時,Test Run Time不要太長,Stress Level以及Stress multiplier不要太大。第一次運行的目的只是為了檢驗測試腳本正確的運行。 5 測試結(jié)果每次測試運行結(jié)束后WAS會生成詳細(xì)的報表,即使測試被提前停止也一樣。WAS報表可以從View 菜單選擇Reports查看。下面介紹一下報表中幾個重要的部分。5.1 摘要頁面摘要部分提供了頁面的名字,接收到第一個字節(jié)的平均時間(TTFB,接收到最后一個字節(jié)的平均時間(TTLB,以及測試腳本中各個頁面的命中次數(shù)。TTFB和TTLB這兩個值對于計算客戶端所看到的

20、服務(wù)器性能具有重要意義。TTFB反映了從發(fā)出頁面請求到接收到應(yīng)答數(shù)據(jù)第一個字節(jié)的時間總和(以毫秒計,TTLB包含了TTFB,它是客戶機(jī)接收到頁面最后一個字節(jié)所需要的累計時間。只要選中頁面的名字,即可顯示頁面概要。 5.2 Result Codes如 果 這 是 一個 新 創(chuàng)建 的測試 腳 本,你應(yīng) 該 檢 查 一 下 報 表 的 Result Codes部 分 。這 部 分 內(nèi)容 包含 了 請 求 結(jié) 果 代碼、 說明 以及服務(wù)器 返 回 的 結(jié) 果 代碼 的數(shù)量。如 果 這 里 出現(xiàn) 了 404代碼 (頁 面 沒 有 找 到 , 說 明 在 腳 本中 有 錯誤 的 頁 面 請 求 。具 體

21、的 錯誤 代碼 表 示 的 意義 , 可 以 參考 IIS 的 說明 文 檔 。5.3 Perf Counters報 表 中 還 包含 了 所 有 性能 計 數(shù)器的 信息 。這 些 數(shù)據(jù) 顯示 了 運行 時 各 個 項目 的測量 值 , 同 時 還 提供了 最大 值 、 最 小 值 、 平均 值等 。 報 表實際 提供的 信息 遠(yuǎn)遠(yuǎn)超 過 了我們這 里 能夠 介紹 的 內(nèi)容 。5.4 Script Settings這 里 顯示 的 是運行 本 次 測試時的 設(shè)置 ,也 就 是 前 面 講到 的 Setting 部 分 的 內(nèi)容 。5.5 Test Clients這 里 顯示 的 是 各 個 W

22、AS 客 戶 機(jī) 的情況。 先 總 體 說明 在測試中使用了 那 些 WAS 客 戶 機(jī) ,在使用的 WAS 客 戶 機(jī) 中 顯示l 執(zhí) 行 了 多 少線 程l 模擬了 多 少 用戶l 點擊 的 次 數(shù)l 連 接 失敗 的 次 數(shù)5.6 Page Summary顯示 了在測試中 各 個 請 求 內(nèi)容 的 TTFB 和 TTLB ,以及 點擊 的 次 數(shù) 等信息 。具 體 的 說明 已 經(jīng) 包含 在 5.1摘 要 中5.7 Page Groups顯示 不同 的用戶 組 在測試中的 執(zhí) 行 情況。這 里 提供的 信息 包括l 用戶 組 的 分布 情況,以及在 所 有 用戶 組 中 所 占 的 比例

23、l 點擊 的 次 數(shù),以及在 所 有 點擊 次 數(shù)中 所 占 的 比例l Result Codes情況l Socket 連 接 的 信息5.8 Page Data顯示 了 各 個 請 求 內(nèi)容 的 更加 詳細(xì) 的 信息 。 技術(shù) 需 求 中的 運行 效 率 信息 可 以在這 里驗證 。25%、 50%、 75%的數(shù) 字還沒有弄明白什么意思?平均值還 不 知道怎 樣計 算 出 來 的 6 其他方式編寫測試腳本在前 邊 提 到 , 編 寫 測試 腳 本 有 4種方法, 現(xiàn) 在對 其他三 種方法 進(jìn)行 簡單的 介紹6.1 手動編寫 測試腳本打 開 菜 單, 選擇 Scripts|Create|Man

24、ual 手動創(chuàng)建 一個測試 腳本 然 后 出現(xiàn) 了 NewScript , server中 輸 入要進(jìn)行 測試的服務(wù)器 IP 地址 或 計 算 機(jī) 名稱 ; 在 腳 本的 內(nèi)容表 格 中verb項 選擇腳 本 運行 方 式 get、 post 、 head ; path中 輸 入 向 服務(wù)器提 交 的文件 或 字 符串。 6.2 導(dǎo)入 IIS 日志這種方法 適合于 開 始 投入運行 的 Web 應(yīng)用程序。 IIS 日 志記錄 了用戶訪問 系統(tǒng) 的 所 有 信息 。 通 過導(dǎo) 入 IIS 日 志 的方法 建 立 的測試 腳 本, 是 最 符 合 實際運行 情況的方法。如 果 有 IIS 日 志

25、,我們 推薦 使用這種方 法。這種方法也 比 較 簡單。 打 開 菜 單, 選擇 Scripts|Create|Log 導(dǎo)入 IISs 日 志創(chuàng)建 一個測試 腳 本。然 后 出現(xiàn)導(dǎo)入 IIS 日 志 的 第 一 步 , 選擇 IIS 日 志 的 路徑 , 默認(rèn) 情況 下 的 路徑 如 圖 所 示Next 進(jìn)入 第 二 步 ,一 般 情況 下不 用 做 改 動 。 取 默認(rèn) 即可Finish 后 , WAS 自 動 生 成 腳 本。6.3 導(dǎo)入網(wǎng)站內(nèi)容文件 這種方法通過導(dǎo)入網(wǎng)站上具體的文件來生成測試腳本。一般情況下，不推薦使用這種方法。下面 簡單說明這種方法的使用。 打開菜單，選擇Scripts

26、|Create|Contents ，WAS自動新建一個測試腳本，并且切換到Contents Tree節(jié) 點。 然后回到New Script的主頁面，會看到選擇的內(nèi)容文件自動添加到表格中 使用方法就是這樣。 7 初步的想法 1 在大規(guī)模的測試時，需要很多WAS客戶端。為了充分利用資源，可以在項目組每個人的機(jī)器上都 安裝WAS軟件（只要正確安裝，啟動WebTool服務(wù)即可）。這樣測試時，WAS會自動協(xié)調(diào)，自動分 配線程。 2 我們的系統(tǒng)中有很多的角色。雖然WAS可以將不同角色執(zhí)行請求的順序進(jìn)行混合，但是這樣我們 不知道WAS怎樣混合的，不能隨時控制角色的狀態(tài)。建議將不同的角色分組，每個角色放到一個

27、 WAS測試機(jī)（充當(dāng)控制器）上，這樣可以分角色而又集中的對WebServer進(jìn)行壓力測試，同時又能 隨意的控制各個WAS客戶機(jī)的狀態(tài)。這種思想是模仿LoadRunner軟件，具體實施還需要不斷的實驗 和學(xué)習(xí)。 3 在集成測試時，先注重性能方面的測試，逐步的加壓，尋找WebServer的最大負(fù)載量。進(jìn)而對照技 術(shù)需求，不斷改進(jìn)。 4 WAS首先是性能測試工具，然后才是壓力測試工具。具體測試時，可以先在正常的條件下（滿足 技術(shù)需求）進(jìn)行性能測試，然后才是異常情況（增加壓力到技術(shù)需求規(guī)定的1.5-2倍）的測試。 5 不斷的研究學(xué)習(xí)，利用WAS更深入地了解你的應(yīng)用的性能、穩(wěn)定性、瓶頸和局限性。 8 存

28、在的問題 目前存在的問題： 1 在測試結(jié)果Report中的Page Data部分，25%、50%、75%的值到底是什么意思？Average又是怎樣計算 出來的 2 在關(guān)于身份驗證的頁面中，如何模擬多用戶使用不同的賬號登陸？按照幫助說明和例子的說明，在 ASP.NET開發(fā)的登陸程序中沒有試驗成功。（幫助中這么說明：取用戶名是在POST數(shù)據(jù)項中把用戶名用 “%Username%”代替，密碼用“%Password%”代替） 3 添加性能計數(shù)器時，添加本機(jī)的當(dāng)然沒有問題。但是如何添加服務(wù)器的性能計數(shù)器。這需要在服 務(wù)器端進(jìn)行設(shè)置，但怎樣設(shè)置？還沒有弄清楚。（這個問題已經(jīng)清楚了，服務(wù)器端不需要任何設(shè)置，

29、 只要客戶機(jī)和服務(wù)器在一個工作組即可） 9 性能優(yōu)化 以下文字摘自網(wǎng)絡(luò)上的文章。僅供參考。 隨著Internet應(yīng)用的日益廣泛，用戶的要求和期望也在不斷地發(fā)展。今天的客戶期待個性化的可定制 的方案，期待這些方案不僅簡單，而且快速、可靠、成本低廉。對于能夠適應(yīng)用戶需求不斷變動的可定 制頁面來說，靜態(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ù)之類的任務(wù)現(xiàn)在可以由服 務(wù)器執(zhí)行而無需客戶干預(yù)。然而，這些變革也導(dǎo)致了一個結(jié)果，這

30、就是許多網(wǎng)站都在使用大量的未經(jīng)優(yōu) 化的數(shù)據(jù)庫調(diào)用，從而使得應(yīng)用性能大打折扣。 我們可以使用以下幾種方法來解決這些問題： 1. 優(yōu)化ASP代碼。 2. 優(yōu)化數(shù)據(jù)庫調(diào)用。 3. 使用存儲過程。 4. 調(diào)整服務(wù)器性能。 優(yōu)秀的網(wǎng)站設(shè)計都會關(guān)注這些問題。然而，與靜態(tài)頁面的速度相比，任何數(shù)據(jù)庫調(diào)用都會顯著地影 響Web網(wǎng)站的響應(yīng)速度，這主要是因為在發(fā)送頁面之前必須單獨地為每個訪問網(wǎng)站的用戶進(jìn)行數(shù)據(jù)庫調(diào) 用。 這里提出的性能優(yōu)化方案正是基于以下事實：訪問靜態(tài)HTML頁面要比訪問那些內(nèi)容依賴于數(shù)據(jù)庫 調(diào)用的頁面要快。它的基本思想是：在用戶訪問頁面之前，預(yù)先從數(shù)據(jù)庫提取信息寫入存儲在服務(wù)器上 的靜態(tài)HTML頁

31、面。為了保證這些靜態(tài)頁面能夠及時地反映不斷變化的數(shù)據(jù)庫數(shù)據(jù)，必須有一個調(diào)度程 序管理靜態(tài)頁面的生成。 當(dāng)然，這種方案并不能夠適應(yīng)所有的情形。例如，如果是從持續(xù)變化的大容量數(shù)據(jù)庫提取少量信 息，這種方案是不合適的。不過可以適用該方案的場合還是很多。 為了保證能夠在合適的時間更新靜態(tài)HTML頁面，把下面的代碼加入到相應(yīng)的ASP頁面前面： < % lastUpdated=Application("LastUpdated" presentTime=now if DATEDIFF("h",lastUpdated,presentTime >= 1 the

32、n Application ("LastUpdated" =presentTime response.redirect "Update.asp?physicalpath="&Request.ServerVariables("PATH_TRANSLATED" end if % > < html > Static content goes here < /html > 每當(dāng)該頁面被調(diào)用，腳本就會提取最后的更新時間并將它與當(dāng)前時間比較。如果兩個時間之間的差 值大于預(yù)定的數(shù)值，Update.asp腳本就會

33、運行；否則，該ASP頁面把余下的HTML代碼發(fā)送給瀏覽器。 最后更新時間從Application變量得到，它的第一次初始化由global.asa完成。具體的更新時間間隔應(yīng) 根據(jù)頁面內(nèi)容的更新要求調(diào)整。 如果每次訪問ASP頁面的時候都要提供最新的信息，或者輸出與用戶輸入密切相關(guān)，這種方法并不 實用，但這種方法可以適應(yīng)以固定的時間間隔更新信息的場合。 如果數(shù)據(jù)庫內(nèi)容由客戶通過適當(dāng)?shù)腁SP頁面更新，要確保靜態(tài)頁面也能夠自動反映數(shù)據(jù)的變化，我 們可以在ASP頁面中調(diào)用Update腳本。這樣，每當(dāng)數(shù)據(jù)庫內(nèi)容改變時服務(wù)器上也有了最新的靜態(tài)HTML 頁面。 另一種處理頻繁變動數(shù)據(jù)的辦法是借助Microsft SQL Server 7.0的Web助手向?qū)В╓eb Assistant Wizard），這個向?qū)軌蚶肨ransact-SQL、存儲過程等從SQL Server數(shù)據(jù)生成標(biāo)準(zhǔn)的HTML文件。 利用SQL Server任務(wù)，Web助手向?qū)軌蛴脕矶ㄆ诘厣蒆TML頁面。正如前面概要介紹的方案， Web助手可以通過觸發(fā)子更新HTML頁面，比如在指定的時間執(zhí)行更新或者在數(shù)據(jù)庫數(shù)據(jù)變化時執(zhí)行更 新。 SQL Server使用名為sp_makewebtask的存儲過程創(chuàng)建HTM