肖弋

達州職業(yè)技術學院 四川 635000

0 引言

一般而言，人們對一個WEB站點的性能如何，通常都是處于用戶的角度，通過訪問站點的頁面，體驗等待所用的時間。當用戶輸入頁面地址后，瀏覽器便向服務器發(fā)出一系列請求，這些請求不光包含了對頁面的請求，還包括頁面中組件的請求，如：圖片，層疊樣式表(CSS)、腳本(Script)、內(nèi)嵌頁面(iframe)等。然后瀏覽器等待服務器的響應之后返回數(shù)據(jù)，瀏覽器獲得返回數(shù)據(jù)又要經(jīng)過本地的計算和渲染，最終呈現(xiàn)完整的頁面。

整個過程看似并不復雜，事實上并不簡單。對于站點經(jīng)營者來說，用戶等待的時間過長，也許后果就是毀滅性的。在等待的時間里，數(shù)據(jù)在網(wǎng)絡上傳輸?shù)臅r間包括兩部分，即瀏覽器主機發(fā)出請求數(shù)據(jù)到達服務器的時間，以及服務器的響應數(shù)據(jù)回到主機的時間，它的決定因素主要包括發(fā)送的數(shù)據(jù)量和網(wǎng)絡帶寬。同時，站點服務器處理請求并生成響應數(shù)據(jù)的時間主要消耗在服務器端，也包括非常多的環(huán)節(jié)，我們一般用一個指標“吞吐率”來衡量，即每秒處理的請求數(shù)。影響服務器的吞吐率的因素有很多，如服務器的并發(fā)策略、I/O性能、CPU核數(shù)等，當然也包括應用程序本身的邏輯復雜度等。在瀏覽器本地計算和渲染的時間自然消耗在瀏覽器端，它依賴的瀏覽器采用的并發(fā)策略、樣式渲染方式、腳本解釋器的性能、頁面大小、頁面組件的數(shù)量、頁面組件緩存狀態(tài)、頁面組件域名分布以及DNS解析等。

可見，一個頁面包含了若干個請求，每個請求都會影響頁面打開的時間，那么要構建高性能WEB站點，應從以下幾個方面進行解決。

1 解決方案

1.1 增加帶寬

當WEB站點的網(wǎng)頁或者組件下載速度變慢時，架構師可能想到最省事的辦法就是增加服務器的帶寬，因為他們認為是服務器帶寬不夠用了，對于一些以提供下載服務為主的站點來說也許是這樣，但對于其他服務的站點，也許不一定就是增加帶寬的問題，在增加帶寬的同時，還要考慮數(shù)據(jù)的網(wǎng)絡傳輸，如帶寬是獨享還是共享，數(shù)據(jù)發(fā)送的速度，響應的時間等方面的問題。

1.2 減少網(wǎng)頁中的HTTP請求

我們都知道WEB站點中幾乎任何一個網(wǎng)頁都包含了多個組件，每個組件都需要下載、計算或渲染，毫無疑問，這些行為都會消耗時間。那么如果可以讓網(wǎng)頁減少這些行為，應該就可以加快網(wǎng)頁的展示速度，這是毫無疑問的，但是往往我們需要在優(yōu)雅的網(wǎng)頁表現(xiàn)和性能之間來權衡取舍，這也許就是美和快之間的博弈，找到最優(yōu)的均衡點至關重要，我們?yōu)榇俗隽硕喾矫娴膰L試和努力：

(1) 設計更加簡單的網(wǎng)頁，使其包含較少的圖片和腳本，但是這可能犧牲美觀和用戶交互。

(2) 將多個圖片合并為一個文件，利用CSS背景圖片的偏移技術呈現(xiàn)在網(wǎng)頁中，避免了多個圖片的下載。

(3) 合并JAVASCRIPT腳本或者CSS樣式表。

(4) 充分利用HTTP中的瀏覽器端CACHE策略，減少重復下載。

很顯然，這些技巧都來自于WEB網(wǎng)頁前端的優(yōu)化。

1.3 加快服務器腳本計算速度

我們知道，腳本語言編寫的程序文件需要通過響應的腳本解釋器進行解釋后生成中間代碼，然后依托在解釋器的運行環(huán)境中運行。所以生成中間代碼的這部分時間又成為大家為獲取性能提升而瞄準的一個目標，對于一些擁有較強商業(yè)支持的腳本語言，比如ASP.NET和JSP，均有內(nèi)置的優(yōu)化方案，比如解釋器對某個腳本程序第一次解釋的時候，將中間代碼緩存起來，以供下次直接使用。

1.4 使用動態(tài)內(nèi)容緩存

動態(tài)內(nèi)容技術就像WEB開發(fā)領域的一場工業(yè)革命，它帶來了產(chǎn)業(yè)升級和WEB開發(fā)者的地位提升，自動態(tài)內(nèi)容技術產(chǎn)生后，為了減少動態(tài)內(nèi)容的重復計算，想到了截取動態(tài)內(nèi)容的勝利果實，將動態(tài)內(nèi)容的HTML輸出結果緩存起來，在隨后的一段時間內(nèi)當有用戶訪問時便跳過重復的動態(tài)內(nèi)容計算而直接輸出。在實際應用中，動態(tài)內(nèi)容緩存可能是大家使用最多的技術，但是并不見得所有的動態(tài)內(nèi)容都適合使用網(wǎng)頁緩存，緩存帶來的性能提升恰恰與有些動態(tài)數(shù)據(jù)實時交互的需求形成矛盾，這是非常尷尬的，而解決問題的惟一途徑不是技術本身，而是你如何權衡。

1.5 使用數(shù)據(jù)緩存

動態(tài)內(nèi)容緩存是將數(shù)據(jù)和表現(xiàn)整體打包，就像快餐店里的組合套餐一樣，有時候未必完全合乎口味。當我們意識到在自己的站點中，某些動態(tài)內(nèi)容的計算時間其實主要消耗在一些煩人的特殊數(shù)據(jù)上，這些數(shù)據(jù)或者更新過于頻繁，或者消耗大量的I/O等待時間，比如對關系數(shù)據(jù)庫中某字段的頻繁更新和讀取，這時為了提高緩存的靈活性和命中率，以及性能的要求，便開始考慮數(shù)據(jù)緩存。更加細粒度的數(shù)據(jù)緩存避免了過期時大量相關網(wǎng)頁的整體更新，比如很多動態(tài)內(nèi)容都包含了一段公用的數(shù)據(jù)，如果我們將整個頁面全部緩存，那么假如這段數(shù)據(jù)頻繁更新導致頻繁過期，無疑會使得所有網(wǎng)頁都要頻繁地重建緩存，這對網(wǎng)頁的其他部分內(nèi)容似乎很不公平，所有需要考慮協(xié)調網(wǎng)頁緩存和數(shù)據(jù)緩存。另外，數(shù)據(jù)緩存存儲的位置也是需要考慮的多方面因素。速度是一方面，如果無法提供高速的讀寫訪問，那么數(shù)據(jù)緩存可能不久便成為新的系統(tǒng)瓶頸。另外數(shù)據(jù)緩存的共享也是至關重要，如同一主機上不同進程間的共享、網(wǎng)絡上不同主機間的共享等，一旦設計不當，對站點未來的擴展也是致命的威脅。

1.6 將動態(tài)內(nèi)容靜態(tài)化

在動態(tài)內(nèi)容緩存技術的實現(xiàn)機制中，雖然避免了可觀的重復計算，但每次還需要調用動態(tài)腳本解釋器來判斷緩存是否過期以及讀取緩存，這似乎有些多余，而且關鍵是消耗了不少時間。直接讓瀏覽器訪問這些動態(tài)內(nèi)容的緩存不是更好嗎？在這種情況下緩存成為直接暴露給前端的HTML網(wǎng)頁，而緩存控制機制也發(fā)生了根本的變化，我們稱它為靜態(tài)化，靜態(tài)網(wǎng)頁獨立了，不用被腳本解釋器呼來喚去。

1.7 頁面組件分離

在WEB站點中，顯然網(wǎng)頁和各種各樣的組件它們的下載量和對服務器的能力要求不盡相同，如果由同一臺物理服務器或者同一種并發(fā)策略的WEB服務器軟件來統(tǒng)一提供服務，那勢必造成計算資源的浪費以及并發(fā)策略的低效。所以分離帶來的好處是顯而易見的，那就是可以根據(jù)不同的組件的需求，比如下載量、文件大小、對服務器各種資源的需求等，有針對性地采用不同的并發(fā)策略，并且提供最佳的物理資源。

1.8 合理部署服務器

我們都知道，在基于 IP尋址的互聯(lián)網(wǎng)中，IP地址相近的主機之間通信，數(shù)據(jù)經(jīng)過少數(shù)的路由器即可到達，比如同一個局域網(wǎng)內(nèi)通信或者接入同一個城市交換節(jié)點的局域網(wǎng)之間通信，在這種情況下數(shù)據(jù)到達時間相對較短。所以WEB站點服務器部署合理可以減少用戶訪問數(shù)據(jù)達到的時間。

1.9 使用負載均衡

至此，我們已經(jīng)最大程度發(fā)揮了單個服務器的處理能力，但是，當它所承受的壓力達到極限時，就需要有更多的服務器來分擔工作，這時需要將流量合理轉移到更多的服務器上。為此，可以通過各種不同的方法來實現(xiàn)WEB負載均衡，可能是簡單的HTTP重定向，或者基于DNS的輪詢解析，或者通過反向代理服務器來實現(xiàn)負載均衡調度，還可以通過LVS來組建服務器集群等。

1.10 優(yōu)化數(shù)據(jù)庫

WEB服務器與數(shù)據(jù)庫服務器的數(shù)據(jù)通信一般基于標準TCP，其通信連接的建立和釋放涉及代表一段內(nèi)核高速緩沖區(qū)的文件描述符的創(chuàng)建和銷毀，這需要不少的時間開銷，包括系統(tǒng)調用導致的內(nèi)核態(tài)切換以及某些異步阻塞 I/O模型采用的文件描述符隊列掃描機制。所以，頻繁的數(shù)據(jù)庫連接和釋放無疑將導致數(shù)據(jù)訪問等待時間的加長，使用數(shù)據(jù)庫持久連接有效的解決了這一難題，它包括不同程度上的持久化，本質的區(qū)別在與持久連接的應用范圍和生命周期，比如某個進程內(nèi)部的全局數(shù)據(jù)庫連接，供進程內(nèi)所有計算機任務共享，在這個進程終止后便被釋放；或者在某個動態(tài)內(nèi)容的執(zhí)行周期內(nèi)，代碼層的持久連接對象，在動態(tài)內(nèi)容計算結束后便不復存在等，這在連接設計時，還需注意數(shù)據(jù)訪問的安全性。

隨著時間的推移，WEB站點逐漸被數(shù)據(jù)庫綁架，單臺數(shù)據(jù)庫服務器無法應付整個站點的需要，這包括存儲空間以及查詢時間，數(shù)據(jù)庫模型的不良設計制約橫向擴展以及負載均衡，為此，數(shù)據(jù)散列在多臺主機，包括必要的冗余數(shù)據(jù)，來合理地分散數(shù)據(jù)庫的密集訪問等，這都要求必須對數(shù)據(jù)庫進行優(yōu)化。

2 結束語

隨著時間的推移，高性能WEB站點研究的空間還很大，WEB站點在成長的道理上不斷吸收新的技術，然而每一次技術的應用不當，都可能讓我們面臨新的威脅，只有不斷地改善才能構建出高性能的WEB站點。

[1] 王春紅.中小企業(yè)網(wǎng)站安全問題與防范策略研究[J].現(xiàn)代計算機(專業(yè)版).2010.

[2] 李博,李寧,費中華.校園網(wǎng) WEB 服務器的性能測評及優(yōu)化方案研究[J].電腦知識與應用.2010.

[3] 李春子.網(wǎng)站集群式管理在高校中的應用分析[J].數(shù)字技術與應用.2010.

[4] 陳紅紅.高校網(wǎng)站管理問題分析及解決方案[J].西北成人教育學報.2009.