新聞中心

EEPW首頁(yè) > 網(wǎng)絡(luò)與存儲(chǔ) > 設(shè)計(jì)應(yīng)用 > Web應(yīng)用中縮短Web響應(yīng)時(shí)間的技術(shù)研究

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

作者:張曉麗,于海燕 時(shí)間:2008-09-25 來(lái)源:中電網(wǎng) 收藏

  1 引 言

本文引用地址:http://butianyuan.cn/article/88374.htm

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

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

  2 Web響應(yīng)時(shí)間

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

  客戶端和Web之間HTTP信息的傳送是通過(guò)TCP連接實(shí)現(xiàn)的。圖1描述Web請(qǐng)求中的所有時(shí)間延遲??蛻舳讼?a class="contentlabel" href="http://butianyuan.cn/news/listbylabel/label/服務(wù)器">服務(wù)器發(fā)送文件請(qǐng)求,首先建立TCP連接(1~3),連接建立后,Web服務(wù)器響應(yīng)且發(fā)送文件至客戶端,客戶端接受文件且在屏幕上顯示出來(lái)(4~5)。如果文件中包含圖片或者需要在屏幕上顯示的處理,客戶端瀏覽器就需要發(fā)送請(qǐng)求去檢索獲取這些(6~n)。整個(gè)Web頁(yè)面在屏幕上顯示,其中可能含有連接,如果用戶點(diǎn)擊連接,瀏覽器就需要使用同樣的過(guò)程檢索新的頁(yè)面。

  根據(jù)圖1和以上分析,定義如下的概念:

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

  定義2 Web數(shù)據(jù)響應(yīng)時(shí)間TWeb設(shè)Tpage為頁(yè)面下載時(shí)間,Tcontent為內(nèi)容生成時(shí)間,則整個(gè)頁(yè)面的響應(yīng)時(shí)間,則:

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

  3 減少數(shù)據(jù)顯示的響應(yīng)時(shí)間

  目前的Web應(yīng)用開發(fā)大多采用基于B/S模式的3層架構(gòu),如圖2所示。

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

  3.1 數(shù)據(jù)訪問(wèn)的優(yōu)化

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

  3.1.1 使用XML技術(shù)

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

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

  (1)建立數(shù)據(jù)庫(kù)連接,生成查詢結(jié)果數(shù)據(jù)集(DataSet);

  (2)用XmlDataDocument將查詢結(jié)果集(DataSet)以XML形式保存在Web服務(wù)器的指定目錄下,同時(shí)斷開數(shù)據(jù)庫(kù)連接;

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

  (4)創(chuàng)建XmlDataDocument對(duì)象,并用其Load方法加載該XML文件;

  (5)利用XPath或者XQuery查詢技術(shù),查詢已加載的XML文件,生成相應(yīng)的結(jié)果集。

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

  3.1.2 使用連接池

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

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

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

  3.2 表示層的數(shù)據(jù)顯示

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

  3.2.1 使用緩存技術(shù)

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

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

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

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

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

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

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

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

  3.2.3 利用DTO減少遠(yuǎn)程調(diào)用次數(shù)

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

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

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

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

  4 測(cè)試結(jié)果及分析

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

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

  5 結(jié) 語(yǔ)

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



評(píng)論


相關(guān)推薦

技術(shù)專區(qū)

關(guān)閉