?????? 1.1? 等待的真相

??? 整個過程聽起來好像并不復雜,也許你從來都沒有考慮過在這段等待的時間里世界都發生了什么變化,也許你早已習慣了利用這段時間東張西望或者品嘗零食,或者你根本沒有來得及意識到這點,新的網頁就已經閃亮登場,恭喜你,你很幸運!但是在這個世界上,幸運兒永遠只占少數,大多數人的大腦處理速度已經讓他們明顯感覺到這段等待時間漫長無比,久經考驗的他們可以隨時身手敏捷地打開多個瀏覽器窗口與時間賽跑,并為此筋疲力盡。

??? 另一方面,對于站點經營者來說,讓用戶等待的時間過長,也許會造成毀滅性的后果。我見過很多人為了享用某家特色小吃而在餐館門口樂此不疲地排著長隊,但沒有聽說有多少用戶執著地等待著一個速度緩慢的站點而不去嘗試別的站點。

??? 在這段等待的時間里,到底發生了什么?事實上這并不簡單,大概經歷了以下幾部分時間:

??? ? 數據在網絡上傳輸的時間

??? ? 站點服務器處理請求并生成回應數據的時間

??? ? 瀏覽器本地計算和渲染的時間

??? 數據在網絡上傳輸的時間總的來說包括兩部分,即瀏覽器端主機發出的請求數據經過網絡到達服務器的時間,以及服務器的回應數據經過網絡回到瀏覽器端主機的時間。這兩部分時間都可以視為某一大小的數據從某主機開始發送一直到另一端主機全部接收所消耗的總時間,我們稱它為響應時間,它的決定因素主要包括發送的數據量和網絡帶寬。數據量容易計算,但是究竟什么是帶寬呢?我們將在后續章節中詳細介紹帶寬的本質。

??? 站點服務器處理請求并生成回應數據的時間主要消耗在服務器端,包括非常多的環節,我們一般用另一個指標來衡量這部分時間,即每秒處理請求數,也稱吞吐率,注意這里的吞吐率不是指單位時間處理的數據量,而是請求數。影響服務器吞吐率的因素非常多,比如服務器的并發策略、I/O模型、I/O性能、CPU核數等,當然也包括應用程序本身的邏輯復雜度等。這些將在后續章節中詳細介紹。

??? 瀏覽器本地計算和渲染的時間自然消耗在瀏覽器端,它依賴的因素包括瀏覽器采用的并發策略、樣式渲染方式、腳本解釋器的性能、頁面大小、頁面組件的數量、頁面組件緩存狀況、頁面組件域名分布以及域名DNS解析等,并且其中一些因素隨著各廠商瀏覽器版本的不同而略有變化。這部分內容我們在后續章節中也會適當提到。

??? 可見,一個頁面包含了若干個請求,每個請求都或多或少地涉及以上這些過程,假如有一處關鍵環節稍加拖延,整體的速度便可想而知。

??? 現在,如果有用戶向你抱怨在打開站點首頁的時候等待了很久,你知道究竟慢在哪里了嗎?

??? 1.2? 瓶頸在哪里

??? 相信你一定知道赤壁之戰,這是中國歷史上一場著名的以少勝多的戰役,東吳的任務是擊退曹操的進攻,要完成這項任務,可謂“萬事俱備,只欠東風”,這時東風便是決勝的瓶頸,所以很多系統論研究專家將其稱為“東風效應”,也就是社會心理學里講的“瓶頸效應”。

??? 之所以稱它為瓶頸,是因為盡管東吳做了很多的戰前準備,包括蔣干中計導致曹操錯殺蔡瑁和張允、諸葛亮草船借箭、東吳苦練水軍等,但是僅靠這些仍無法獲得最終勝利,還需要最后的東南風才能一錘定音,完成火燒曹軍戰船的計劃。不過之前的準備工作都是勝利的子因素,而東南風這個關鍵因素最終和其他子因素一起相互作用,將整個戰斗的殺傷力無限放大。

??? 曹操運氣不好,遇上東南風,倒了大霉,曹軍戰船一片火海,這時候東吳需要派出勇猛的陸軍部隊登岸攻下曹營,可是東吳向來精通水戰,幾乎沒有強大的陸戰部隊,只有老將黃蓋,這如何與曹操的精英騎兵抗衡呢?這個時候決勝的關鍵因素變成了劉備的盟軍支援,五虎上將各個威猛無比,身懷必殺絕技,此時正是上岸一顯身手的好機會,他們不費吹灰之力就將曹軍打得落花流水,試想如果沒有劉備的支援,赤壁一戰勝敗可能就撲朔迷離了。

??? 可見,系統性能的瓶頸,是指影響性能的關鍵因素,這個關鍵因素隨著系統的運行又會發生不斷的變化或遷移,比如由于站點用戶組成結構的多樣性和習慣的差異,導致在不同時段系統的瓶頸各不相同,又如站點在數據存儲量或瀏覽量增長到不同級別時,系統瓶頸也會發生遷移。一旦找到真正影響系統性能的主要因素,也就是性能瓶頸,就要堅決對其進行調整或優化,因為你不得不這么做。

??? 提示:

??? 中醫是一門關于生命的哲學,也是中國人智慧的結晶,它的光芒在于獨到的思辨能力和系統性的分析方法,它認為世間萬物都在不停地變化,并賦予它們陰陽狀態,包括天地、季節、天氣、心理、生理等,而患者的病理也在隨之變化,所以,中醫會對同一位患者在不同季節進行不同的診斷,找到不同的病因。

??? 同時,在這些關鍵因素的背后,也存在很多不能忽略的子因素,構成了性能優化的“長尾效應”,也就是說如果你對某個子因素背后的問題進行優化,可能會帶來性能上的少許提升,也許不被察覺,但是多個子因素的優化結果也許會疊加在一起,帶來性能上可觀的提升。對于諸多子因素的優化,需要稍加謹慎,花點時間考慮這種優化是否值得,以及是否會帶來潛在的副作用,還有其他依賴的非技術因素。

??? 然而,不論是關鍵因素還是子因素,它們的背后都是影響系統性能的問題所在,問題本身并不涉及關鍵性,只有在不同的系統和應用場景下,才會顯示出其是否關鍵。

??? 本章的其余部分將先列出一些我們經常遇到的問題,并簡單介紹我們常用的優化方案,至于這些問題在什么時候是否關鍵,它們的本質是什么,以及如何調整或優化,在后續章節中我們將結合具體場景來詳細探討包括這些在內的更多主題,這也是本書貫穿始終的線索。

??? 1.3? 增加帶寬

??? 當Web站點的網頁或組件的下載速度變慢時,一些架構師可能想到的最省事的辦法就是增加服務器帶寬,因為他們認為是服務器帶寬不夠用了,對于一些以提供下載服務為主的站點來說也許是這樣的,但是對于其他服務的站點,你知道站點當前究竟使用了多少帶寬嗎?這些帶寬都用到哪里了呢?如何計算站點現在和可預見未來使用的帶寬?帶寬增加后下載速度就可以加快嗎?使用獨享帶寬和共享帶寬的本質區別是什么?如何節省帶寬?還有,你可能會忍無可忍地問,究竟什么是帶寬?

??? 對于帶寬的概念,如果你沒有仔細閱讀計算機網絡教材中的描述,我敢肯定你一定是完全憑借自己的理解來認識它的,因為這個詞實在是太有創意了,也實在太容易從字面理解了,但是這些認識從本質上講是完全錯誤的,正是基于這種誤解,很多人都無法完全解答上述那一連串問題,導致在所有涉及帶寬的問題上,只能依靠經驗和猜想。

??? 在后續章節中,我們將通過介紹數據的網絡傳輸原理,徹底揭開帶寬的本質,以及數據傳輸響應時間的依賴因素和計算方法。搞清楚這些一點都不困難,它們是一個優秀架構師必須掌握的基礎知識。

??? 1.4? 減少網頁中的HTTP請求

??? 我們知道Web站點中幾乎任何一個網頁都包含了多個組件,每個組件都需要下載、計算或渲染,毫無疑問,這些行為都會消耗時間。那么如果可以讓網頁減少這些行為,應該就可以加快網頁的展示速度,這是毫無疑問的,但是往往我們需要在優雅的網頁表現和性能之間權衡取舍,這也許是美和快之間的博弈,找到最優的均衡點至關重要,我們為此做了很多嘗試和努力:

??? ? 設計更加簡單的網頁,使其包含較少的圖片和腳本,但是這可能犧牲了美觀和用戶交互。

??? ? 將多個圖片合并為一個文件,利用CSS背景圖片的偏移技術呈現在網頁中,避免了多個圖片的下載。

??? ? 合并JavaScript腳本或者CSS樣式表。

??? ? 充分利用HTTP中的瀏覽器端Cache策略,減少重復下載。

??? 很顯然,這些技巧都來自于Web網頁前端的優化,在后續章節中我們會有所涉及,但是不作為本書的重點來介紹,本書將更加偏重于站點服務器端的性能改善和規模擴展。

??? 1.5? 加快服務器腳本計算速度

??? 我想大多數涉及性能問題的站點都會使用各種各樣的服務器端腳本語言,比如主流的PHP、Ruby、Python、ASP.NET、JSP等,這些腳本語言用來編寫動態內容或者后臺運行的小程序,已經成了幾乎所有站點的首選。而曾經使用C++編寫動態內容的經歷也讓我記憶猶新,除了每天都在感嘆C++的嚴謹和優雅之外,我找不到其他任何好處。

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

??? 對于開源類的腳本語言,也有很多第三方組件來提供此類功能,比如PHP的APC組件等。使用這些組件進行腳本優化真的那么有用嗎?不同的應用效果是否有所不同呢?在后續章節中我們會詳細探討。

總結

以上是生活随笔為你收集整理的《构建高性能Web站点》的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。