Web應用中縮短Web響應時(shí)間的技術(shù)研究

　　1 引 言

　　性能是Web應用程序成功與否的關(guān)鍵因素，響應時(shí)間則是性能的一個(gè)重要指標，尤其是從用戶(hù)的角度來(lái)看，隨著(zhù)同時(shí)訪(fǎng)問(wèn)的用戶(hù)數的增加，Web應用程序的響應時(shí)間也會(huì )相應增加，當其增加到用戶(hù)無(wú)法接受的程度時(shí)，用戶(hù)便會(huì )失去耐心而離開(kāi)該網(wǎng)站。根據Zona Research的研究指出，如果使用者等待下載網(wǎng)頁(yè)的時(shí)間超過(guò)8 s，將有30％的用戶(hù)選擇停止瀏覽網(wǎng)頁(yè)，同樣的研究表明，如果下載網(wǎng)頁(yè)的時(shí)間縮短1 s，則這個(gè)數字將從30％降低到8％。由此可見(jiàn)終端用戶(hù)所感到的時(shí)間延遲(user-perceivedlatency)已經(jīng)成為今天Internet的主要性能問(wèn)題。

　　在網(wǎng)絡(luò )帶寬并沒(méi)有得到相對擴充、網(wǎng)絡(luò )流量絕對增加的情況下，是否能找到一些有效的辦法，縮短整個(gè)網(wǎng)絡(luò )對用戶(hù)click的響應時(shí)間。本文針對這一問(wèn)題，從Web應用程序開(kāi)發(fā)的角度出發(fā)，通過(guò)提高Web應用程序的性能，從而加速網(wǎng)絡(luò )對用戶(hù)的反應速度，縮短用戶(hù)感知的時(shí)間延遲。

　　2 Web數據響應時(shí)間

　　從終端用戶(hù)的觀(guān)點(diǎn)看，從瀏覽器對網(wǎng)站發(fā)出一個(gè)HTTP GET的請求，一直到網(wǎng)站服務(wù)器完整地傳回網(wǎng)頁(yè)內容至瀏覽器的這段過(guò)程可以描述為圖1所示的時(shí)序圖。

　　客戶(hù)端和Web服務(wù)器之間HTTP信息的傳送是通過(guò)TCP連接實(shí)現的。圖1描述Web請求中的所有時(shí)間延遲?？蛻?hù)端向服務(wù)器發(fā)送文件請求，首先建立TCP連接(1～3)，連接建立后，Web服務(wù)器響應且發(fā)送文件至客戶(hù)端，客戶(hù)端接受文件且在屏幕上顯示出來(lái)(4～5)。如果文件中包含圖片或者需要在屏幕上顯示的處理數據，客戶(hù)端瀏覽器就需要發(fā)送請求去檢索獲取這些數據(6～n)。整個(gè)Web頁(yè)面在屏幕上顯示，其中可能含有連接，如果用戶(hù)點(diǎn)擊連接，瀏覽器就需要使用同樣的過(guò)程檢索新的頁(yè)面。

　　根據圖1和以上分析，定義如下的概念：

　　定義1 用戶(hù)感知時(shí)間Tuser用戶(hù)從瀏覽器對網(wǎng)站發(fā)出一個(gè)HTTP GET的請求，直到服務(wù)器完整地回傳網(wǎng)頁(yè)內容至瀏覽器的這段時(shí)間。

　　定義2 Web數據響應時(shí)間TWeb設Tpage為頁(yè)面下載時(shí)間，Tcontent為內容生成時(shí)間，則整個(gè)頁(yè)面的響應時(shí)間，則：

　　如前面所述，在網(wǎng)絡(luò )帶寬并沒(méi)有擴充的情況下，則式(1)中的Tc這段時(shí)間就是固定的，那么提高網(wǎng)絡(luò )性能的關(guān)鍵就是如何縮短Th+Ti，也就是定義2中的Web數據響應時(shí)間TWeb。在本文中，從開(kāi)發(fā)Web應用程序的角度出發(fā)，從數據訪(fǎng)問(wèn)、減少網(wǎng)絡(luò )通信量以及緩存3個(gè)方面討論縮短Web數據響應時(shí)間的方法，并對這些方法的使用效果作了測試比較。

　　3 減少數據顯示的響應時(shí)間

　　目前的Web應用開(kāi)發(fā)大多采用基于B／S模式的3層架構，如圖2所示。

　　分層分離了邏輯，使得系統結構層次明晰，系統變得靈活和易于維護。圖2很好地說(shuō)明了Web中的分層架構，同時(shí)也描述Web頁(yè)面提取數據顯示的過(guò)程，以下從軟件處理數據的角度分別討論如何縮短數據訪(fǎng)問(wèn)及Web數據顯示延遲，從而縮短Web數據的響應時(shí)間，減少用戶(hù)感知時(shí)間，提高用戶(hù)的滿(mǎn)意度。

　　3.1 數據訪(fǎng)問(wèn)的優(yōu)化

　　對數據的訪(fǎng)問(wèn)速度很大程度上影響應用系統的性能，如果被請求的頁(yè)面是一個(gè)靜態(tài)頁(yè)面或只有一小部分內容需要從數據庫中提取，則它的加載速度比那些需要從數據庫中大量讀取數據或不斷從數據庫接收和更新數據的頁(yè)面要快，因此，對于動(dòng)態(tài)的頁(yè)面來(lái)說(shuō)，對SQL層數據處理的優(yōu)化就顯得非常重要。在Web開(kāi)發(fā)中，除了傳統的改善數據庫結構和優(yōu)化SQL語(yǔ)句外，主要從以下的幾個(gè)方進(jìn)行優(yōu)化。

　　3.1.1 使用XML技術(shù)

　　對于普通數據訪(fǎng)問(wèn)數據庫而言，在數據量不大的情況下，一般性查詢(xún)在執行速度上，不會(huì )有什么問(wèn)題。每次數據提取需要1次網(wǎng)絡(luò )往返，這在應用程序處理海量結果集時(shí)會(huì )影響性能。比如每次查詢(xún)數據在十萬(wàn)數量級，速度問(wèn)題就會(huì )暴露出來(lái)。但是實(shí)際中發(fā)現，在匯總統計查詢(xún)中，用戶(hù)查詢(xún)頻繁但變動(dòng)并不大，因此可以考慮借助XML獲取數據來(lái)解決上述的問(wèn)題。

　　采用XML技術(shù)，可將查詢(xún)的結果生成XML文件保存在Web服務(wù)器上，使客戶(hù)端能夠直接和XML文件進(jìn)行交互，以節省訪(fǎng)問(wèn)數據庫的資源；同時(shí)也可以將XML傳送到客戶(hù)端，在客戶(hù)端恢復為數據集，此后就可以直接在客戶(hù)端進(jìn)行一些操作，而不必和服務(wù)器交互，建立非連接的數據訪(fǎng)問(wèn)以節省時(shí)間。這里采用以下的算法過(guò)程利用XML技術(shù)實(shí)現對數據庫的訪(fǎng)問(wèn)。

　　(1)建立數據庫連接，生成查詢(xún)結果數據集(DataSet)；

　　(2)用XmlDataDocument將查詢(xún)結果集(DataSet)以XML形式保存在Web服務(wù)器的指定目錄下，同時(shí)斷開(kāi)數據庫連接；

　　(3)一旦用戶(hù)發(fā)送訪(fǎng)問(wèn)請求，首先查詢(xún)Web服務(wù)器指定目錄下是否有滿(mǎn)足條件的XML文件，如果存在轉(4)，否則轉(1)；

　　(4)創(chuàng )建XmlDataDocument對象，并用其Load方法加載該XML文件；

　　(5)利用XPath或者XQuery查詢(xún)技術(shù)，查詢(xún)已加載的XML文件，生成相應的結果集。

　　從上面的過(guò)程可以看出，一旦有用戶(hù)發(fā)送查詢(xún)請求，首先將數據庫服務(wù)器中的數據轉化為XML文檔，保存在Web服務(wù)器上，然后查詢(xún)XML文件中的數據，獲取查詢(xún)結果。之后如果有新的請求查詢(xún)相同的記錄時(shí)，可以直接從Web服務(wù)器的XML文件中提取數據而不用再訪(fǎng)問(wèn)數據庫。這對于用戶(hù)頻繁的查詢(xún)匯總操作中，優(yōu)勢非常明顯，且效率很高。這種思想在邏輯上將數據的生成和操作分開(kāi)，同時(shí)節省了和數據庫服務(wù)器建立連接的時(shí)間，將其轉換為對服務(wù)器端XMl文件的讀取，有效地減輕了對系統數據庫服務(wù)器的負荷。

　　3.1.2 使用連接池

　　建立Web應用程序與數據庫之間的TCP連接時(shí)，DBMS需要為其分配多種資源，而在釋放連接時(shí)，DBMS需要釋放掉這些資源，分配和釋放資源都是比較耗時(shí)的工作，因此反復建立和釋放連接勢必會(huì )影響整個(gè)系統的性能。實(shí)際上，大多數應用程序僅使用1個(gè)或幾個(gè)不同的連接配置。這意味著(zhù)在執行應用程序期間，許多相同的連接將反復地打開(kāi)和關(guān)閉。為了使打開(kāi)的連接成本最低，ADO.NET使用連接池的優(yōu)化方法。

　　連接池技術(shù)能夠能重用到數據庫的連接，而不是每次請求都建立新的TCP連接，新連接僅在連接池中得不到連接時(shí)才建立。當連接被關(guān)閉時(shí)，它被返回到連接池中，在那里它仍然保持與數據庫的連接，與完全斷開(kāi)TCP連接相反。池進(jìn)程保持物理連接的所有權。通過(guò)為每個(gè)給定的連接配置保留一組活動(dòng)連接來(lái)管理連接。只要用戶(hù)在連接上調用Open，池進(jìn)程就會(huì )檢查池中是否有可用的連接。如果某個(gè)池連接可用，會(huì )將該連接返回給調用者，而不是打開(kāi)新連接。應用程序在該連接上調用Close時(shí)，池進(jìn)程會(huì )將連接返回到活動(dòng)連接池集中，而不是真正關(guān)閉連接。連接返回到池中之后，即可在下一個(gè)Open調用中重復使用。

　　池連接可以大大提高應用程序的性能和可縮放性。默認情況下，ADO.NET中啟用連接池。除非顯式禁用，否則，連接在應用程序中打開(kāi)和關(guān)閉時(shí)，池進(jìn)程將對連接進(jìn)行優(yōu)化。

　　3.2 表示層的數據顯示

　　對于優(yōu)化B／S下的數據顯示方面，主要考慮數據傳輸量的大小，數據傳輸量的大小是決定顯示響應速度的必要前提，這一點(diǎn)是B／S的弱項。數據傳輸量是指在客戶(hù)端Web瀏覽器和Web服務(wù)器之間傳送的數據量。在用VS.NET開(kāi)發(fā)程序的過(guò)程中，通過(guò)減少網(wǎng)絡(luò )的通信量減少I(mǎi)E瀏覽器和Web服務(wù)器層之間的數據傳數量，縮短用戶(hù)感知時(shí)間。

　　3.2.1 使用緩存技術(shù)

　　合理有效地設計和使用緩存是優(yōu)化應用系統性能的重要手段，在基于Web的支持大量用戶(hù)的系統開(kāi)發(fā)中，這一點(diǎn)尤為明顯。ASP.NET中的緩存能夠提供性能和伸縮性的最大效益、利用有效的緩存、可以避免Web服務(wù)器與數據庫之間的網(wǎng)絡(luò )往返，繞過(guò)占用很多資源的計算，并節省服務(wù)器資源，同時(shí)改善響應時(shí)間和等待時(shí)間。

　　ASP.NET的緩存服務(wù)是一種提高服務(wù)器性能、降低服務(wù)器資源浪費的有效方法。對于安全性要求高的應用程序，采用在WEB服務(wù)器上維護緩存數據的方式可以有效地提高頁(yè)面性能。ASP.NET的緩存對各個(gè)應用來(lái)說(shuō)是私有的，是存儲各種對象的存儲器，緩存的生存周期取決于應用的生存周期，當應用重新啟動(dòng)時(shí)，緩存實(shí)際上已重建。

　　Cache實(shí)現了最近最少使用(least-recently-used)替換算法，允許ASP.NET強制Cache清除操作——如果可用內存下降到低水平——則自動(dòng)從Cache中刪除不使用的項目。另外Cache支持依賴(lài)性到期特性，它能強制包括時(shí)間、鍵值、文件失效。其體系結構如圖3所示。

　　用ASP.NET內置的多級緩存功能，緩存訪(fǎng)問(wèn)過(guò)的ASP.NET頁(yè)面，從而降低Web服務(wù)器的負載，并通過(guò)更高效地提供被緩存的文件而改善WEB系統的性能。ASP.NET提供了幾個(gè)級別的緩存。首先，當一個(gè)ASPX程序第一次被調用的時(shí)候會(huì )被編譯，編譯成功之后，生成的代碼會(huì )自動(dòng)緩存，所以重復運行ASP.NET程序的效率會(huì )有很大的提高。除此之外，ASP.NET還提供輸出緩存(也叫頁(yè)面緩存)、數據緩存(也叫應用程序緩存)和碎片緩存(也叫部分頁(yè)面緩存)。

　　緩存提供一個(gè)簡(jiǎn)單的字典接口，以便于對象放置到緩存中并在以后使用。最簡(jiǎn)單的情況下，放置一個(gè)對象到緩存中，就如同對字典增加一個(gè)條目。在緩存策略上采用“文件和鍵值依賴(lài)”策略。從外部文件或者是其他緩存鍵值是否改變來(lái)決定本身鍵值是否有效。如果依賴(lài)發(fā)生改變，緩存對象將變得不可使用并從緩存中移動(dòng)出來(lái)，從而更新緩沖。代碼如下：

　　3.2.2 避免服務(wù)器和客戶(hù)端的交互

　　HTTP是用于WWW客戶(hù)機和服務(wù)器之間進(jìn)行信息傳輸的協(xié)議，它是一種請求響應類(lèi)型的協(xié)議：客戶(hù)機向服務(wù)器發(fā)送請求，服務(wù)器收到請求后進(jìn)行處理，對這個(gè)請求作出回答。Web瀏覽器包含了許多的HTTP請求，每一個(gè)請求對應一個(gè)小型文件，HTTP對每一個(gè)HTTP請求需要建立1個(gè)獨立的TCP連接。

　　因此，客戶(hù)端的每次請求將會(huì )引起客戶(hù)端和服務(wù)器間的一次通信，頻繁的操作勢必對系統的響應時(shí)間造成嚴重的影響。為避免不必要的TCP連接建立，通常只需在向服務(wù)器查詢(xún)或更新數據時(shí)才觸發(fā)客戶(hù)端與服務(wù)器之間的信息交互。能在客戶(hù)端執行的數據操作應盡可能的用客戶(hù)端腳本(如Javascript)實(shí)現。例如，對用戶(hù)輸入數據的校驗，應該盡量在客戶(hù)端進(jìn)行校驗，再將數據提交給服務(wù)器。

　　3.2.3 利用DTO減少遠程調用次數

　　在分布式架構中，相關(guān)層在物理部署上實(shí)現分離，通過(guò)網(wǎng)絡(luò )或跨進(jìn)程調用遠程對象或服務(wù)。在這種分布式架構中，必須先找到遠程對象位置，而且建立與遠程計算機的連接，然后才能將數據串行化為字節流，然后可能進(jìn)行加密，最后才能將其傳輸到遠程計算機。遠程調用需要跨越網(wǎng)絡(luò )或進(jìn)程，因此會(huì )比較慢。

　　避免遠程調用中固有的滯后時(shí)間問(wèn)題的最佳方法是進(jìn)行更少的調用，并讓每個(gè)調用傳遞更多的數據，這可以通過(guò)定義有效的數據傳輸對象(Data Transfer Object，DTO)來(lái)實(shí)現層與層之間的數據傳輸。

　　創(chuàng )建一個(gè)數據傳輸對象(DTO)，用該對象包含遠程調用所需要的所有數據。修改遠程方法簽名，以便將DTO作為單個(gè)參數接受，并將單個(gè)DTO參數返回給客戶(hù)端。在調用方應用程序收到DTO并將其作為本地對象存儲之后，應用程序可以分別對DTO發(fā)出一系列單獨的過(guò)程調用，而不會(huì )引發(fā)遠程調用開(kāi)銷(xiāo)。如圖4所示。

　　在圖4中，DTO允許遠程對象在單個(gè)遠程調用中將整個(gè)客戶(hù)名稱(chēng)返回給客戶(hù)端，這就將調用次數從3次減為1次?？蛻?hù)端進(jìn)行單個(gè)調用，然后在本地與DTO交互，而不用進(jìn)行多次遠程訪(fǎng)問(wèn)服務(wù)器。通過(guò)使用DTO，在單一遠程調用中傳輸更多的數據信息，減少遠程調用的次數，提高分布式調用的性能。

　　4 測試結果及分析

　　以上方案已在開(kāi)發(fā)系統中得到實(shí)際的應用，并取得了良好的效果。為了測試以上方案的有效性，這里選取系統中有代表的頁(yè)面，利用VS.NET中的ACT(ApplicationCenter Test)工具進(jìn)行壓力測試。在不考慮網(wǎng)絡(luò )傳輸速度的情況下，分別測試原始頁(yè)面和改進(jìn)后的頁(yè)面，得到表1詳細的測試結果：

　　從表1中可以看出，采用上述方案生成的頁(yè)面無(wú)論是在每秒平均請求數還是平均響應時(shí)間上，都有數量級的提高，極大地提高了系統的性能，縮短了Web頁(yè)面的響應時(shí)間，從而縮短用戶(hù)感知延遲時(shí)間，提高用戶(hù)的滿(mǎn)意度。

　　5 結 語(yǔ)

　　在B／S結構的開(kāi)發(fā)中，響應時(shí)間是一個(gè)很重要的指標。本文針對Web應用程序的特點(diǎn)，從軟件處理數據的角度出發(fā)，從優(yōu)化數據訪(fǎng)問(wèn)以及Web數據顯示2方面提出了縮短Web響應時(shí)間方案，并利用ACT測試工具對實(shí)際應用進(jìn)行壓力測試，發(fā)現此方案的可行性。除此之外，還可以通過(guò)優(yōu)化數據庫結構的設計，合理配置應用服務(wù)器所提供的性能優(yōu)化選擇，合理配置編譯器選項等方法對提高Web應用的總體性能。