構建高性能web站點--讀書大綱

用戶輸入你的站點網址，等了半天。。還沒打開，褲衩一下就給關了。好了，流失了一個用戶。爲何會有這樣的問題呢。怎麼解決本身站點「慢」，體驗差的問題呢。

在這段等待的時間裏，到底發生了什麼？事實上這並不簡單，大概經歷瞭如下幾部分時間：
 數據在網絡上傳輸的時間
 站點服務器處理請求並生成迴應數據的時間
 瀏覽器本地計算和渲染的時間

數據在網絡上傳輸的時間總的來講包括兩部分，即瀏覽器端主機發出的請求數據通過網絡到達服務器的時間，以及服務器的迴應數據通過網絡回到瀏覽器端主機的時間。這兩部分時間均可以視爲某一大小的數據從某主機開始發送一直到另外一端主機所有接收所消耗的總時間，咱們稱它爲響應時間，它的決定因素主要包括髮送的數據量和網絡帶寬。數據量容易計算，可是究竟什麼是帶寬呢？咱們將在後續章節中詳細介紹帶寬的本質。

站點服務器處理請求並生成迴應數據的時間主要消耗在服務器端，包括很是多的環節，咱們通常用另外一個指標來衡量這部分時間，即每秒處理請求數，也稱吞吐率，注意這裏的吞吐率不是指單位時間處理的數據量，而是請求數。影響服務器吞吐率的因素很是多，好比服務器的併發策略、I/O模型、I/O性能、CPU核數等，固然也包括應用程序自己的邏輯複雜度等。

瀏覽器本地計算和渲染的時間天然消耗在瀏覽器端，它依賴的因素包括瀏覽器採用的併發策略、樣式渲染方式、腳本解釋器的性能、頁面大小、頁面組件的數量、頁面組件緩存情況、頁面組件域名分佈以及域名DNS解析等，而且其中一些因素隨着各廠商瀏覽器版本的不一樣而略有變化。

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

1.增長帶寬

「帶寬」也許是計算機科學中最幽默的一個詞，當我向一些開發者詢問到底什麼是帶寬的時候，他們的回答老是讓我聯想到相似高速公路的寬度，而當我繼續詢問「咱們的帶寬有多寬」時，他們就會不知所措。
另外一部分開發者顯然知道帶寬的單位是「bit/s」，也就是單位時間的比特數，因此他們將帶寬解釋爲數據在線路中的移動速度，也就是將帶寬的高低視爲線路能力的強弱，那麼很顯然他們認爲光纖對數據的傳播能力大於銅線，但很惋惜，事實上這是錯誤的。順便說一下，咱們通常常說的好比100M帶寬，全稱應該是100Mbit/s，或者100Mbps，後邊的「bit/s」常常省略。

說到數據的發送，也就是數據從主機進入線路的這段旅程，通常須要通過如下幾個環節：
1．應用程序首先得將要發送的數據寫入該進程的內存地址空間中，熟悉網絡編程的開發者對這個環節必定很是熟悉，一般在程序開發中這隻須要通常的運行時變量賦值便可。
2．應用程序經過系統函數庫接口（好比send函數）向內核發出系統調用，由系統內核來進行隨後的操做，它將這些數據從用戶態內存區複製到由內核維護的一段稱爲內核緩衝區的內存地址空間。這塊地址空間的大小一般是有限的，全部要發

送的數據將以隊列的形式進入這裏，這些數據可能來自於多個進程，每塊數據都有必定的額外記號來標記它們的去向。若是要發送的數據比較多，那麼該系統調用須要屢次進行，每次複製必定的數據大小，這個大小取決於網絡數據包的大小以及內核緩衝區的承載能力。重複的系統調用體如今應用編程層面重複調用send函數。
3．當數據寫入內核緩衝區後，內核會通知網卡控制器前來取數據，同時CPU轉而處理其餘進程。網卡控制器接到通知後，便根據網卡驅動信息得知對應內核緩衝區的地址，將要發送的數據複製到網卡的緩衝區中。注意在以上一系列的數據複製中，數據始終按照鏈接兩端設備的內部總線寬度來複制，也就是字節的整數倍，好比在32位總線的主機系統中，採用PCI-X總線接口的網卡通常使用32位總線寬度，那麼從內核緩衝區到網卡緩衝區的數據複製過程當中，任什麼時候刻只能複製32位的比特信息。
4．網卡緩衝區中的數據須要發送到線路中，同時釋放緩衝區來獲取更多要發送的數據。可是咱們知道，只有二進制的數字信號才能夠在線路中傳輸，因此這時候須要對數據進行字節到位的轉換，這種轉換不難想象，就是將數據的每一個位按照順序依次發出。

5．發送時，網卡會使用內部特定的物理裝置來生成能夠傳播的各類信號，好比在使用銅線線路時，網卡會根據「0」和「1」的變化產生不一樣的電信號；而使用光纖線路時，網卡會產生不一樣的光信號。

在大多數狀況下，咱們都將Web站點服務器託管在IDC，經過將其鏈接到某個交換機，從而接入互聯網。這時候，咱們的服務器擁有本身的IP地址，當站點用戶經過互聯網向這臺服務器請求數據後，數據從服務器流經交換機到達指定的路由器，這個過程須要交換機的存儲轉發機制，也就是交換機從鏈接服務器的端口接收數據，存儲到交換機內部的高速緩衝區隊列中，而後將其從鏈接路由器的端口發送出去，再通過路由器的轉發，進入另外一個網絡，接下來依次重複這些過程，直到進入站點用戶的PC。
若是全世界只有你的服務器和你的用戶在傳輸數據，那麼這部分數據流經的每一個交換節點都會全心全意地作好轉發工做，此時你的數據在各節點轉發的發送速度均可以達到理論上設備所能達到的最大值。但實際上每處交換節點都有可能同時轉

發來自其餘主機的數據，包括你的數據在內的全部數據都聚集進入路由器的轉發隊列，路由器按照轉發隊列中的順序來交錯地發送這些來自不一樣主機的數據，因此單歷來自不一樣主機的數據而言，其轉發時的發送速度一定小於全部從路由器轉發出去的數據的發送速度（即該交換節點的出口帶寬）。
由於帶寬是有限的，它毫無疑問是個搶手資源，並且互聯網運營商也不會白白搭建網絡，因此運營商在全部的基礎交換節點上設置關卡，也就是限制數據從你的主機流入路由器轉發隊列的速度，而只要流入路由器轉發隊列的數據，都會按照路由器的出口帶寬，流入其餘網絡。
這種關卡設置實際上等於限制了你的主機發送數據的速度，也就是限制了主機的出口帶寬，而至於這種限制的實現機制，我想你已經很清楚了，那就是經過限制交換機對於你主機的數據接收速度，來將你的發送速度緊緊控制在手，由於數據鏈路層的流量控制是經過控制接收方來實現的。對於交換機的限速設置，IDC的網管很是擅長。

一切都清楚了，下面咱們來看看兩個被交換機限制了帶寬的主機，它們都安裝了MRTG，能夠生成網卡流量報告單，不過咱們在這裏關心的不是流量，而是報告單頂部的一段信息，請注意這裏的Max Speed屬性值，它即是從交換機接收端口得到的最大接收速度，同時也是該主機的最大數據發送速度，但並不必定是此刻的實時發送速度，由於每時每刻的發送速度都是傳輸協議根據接收方的接收能力不斷調整的，好比經過數據鏈路層或者傳輸層的滑動窗口技術等流量控制機制進行速度的調整。
如表2-1所示，這臺主機使用了獨享10M帶寬，也就是10Mbit/s的數據發送速度，換算成字節的話，正好就是上面的1250.0kBytes/s。在這種狀況下，若是路由器的出口帶寬爲100M，交換機的設置應該保證來自廣播域內其餘主機的數據發送速度總和不超過90Mbit/s，以保證該主機任什麼時候刻均可以以10Mbit/s的速度發送數據，這才叫獨享帶寬，它獨享的是路由器的一部分出口帶寬，而不是交換機的帶寬，由於交換機原本就是各個端口獨享帶寬而互不影響。若是這臺交換機還爲其餘主機提供獨享10M帶寬的接入，而且路由器的出口帶寬爲100M，那麼理論上總共只能接入10臺主機，這樣才能夠保證每臺主機的實際帶寬老是10M。假設帶寬運營商爲了多賺錢，給該交換機上接入了20臺主機，而後對每臺交換機仍然都限制了10M帶寬，這時候從MRTG的Max Speed屬性上仍然看到的是1250.0 kBytes/s，可是你能夠觀察MRTG流量圖或者使用Nmon實時流量監控來分析本身的10M帶寬是否真的有所保證。

不管是大文件下載，仍是網頁、圖片、樣式表的下載，其下載速度都是站點用戶最關心的指標，也是用戶惟一能體驗到的站點性能，因此若是能估算出各地用戶的下載速度，並根據它來決策服務器的位置和帶寬，是很是有意義的。在一般狀況下，咱們很清楚也很容易計算傳輸的數據量大小，因此只有搞清楚響應時間的計算方法，才能夠計算出下載速度。

經過前面的介紹，咱們瞭解了互聯網上兩臺主機之間數據發送和傳輸的整個過程，事實上，數據的響應時間不可貴出：響應時間 = 發送時間 + 傳播時間 + 處理時間
發送時間很容易計算，即「數據量/帶寬」。好比要發送100Mbit的數據，並且發送速度爲100Mbit/s，也就是帶寬爲100M，那麼發送時間便爲1s。值得注意的是，在兩臺主機之間每每存在多個交換節點，每次的數據轉發，都須要花費發送時間，那麼總的發送時間也包括這些轉發時所花費的發送時間。
傳播時間主要依賴於傳播距離，由於傳播速度咱們能夠近似認爲約等於2.0×108m/s，那麼傳播時間便等於傳播距離除以傳播速度。好比兩個交換節點之間線路

好比兩個交換節點之間線路的長度爲1 000km，至關於北京到上海的直線距離，那麼一個比特信號從線路的一端到另外一端的傳播時間爲0.005s。
處理時間是什麼意思呢？其實在以前的介紹中，雖然沒有提出這個概念，可是已經包含了對其本質的介紹。簡單地說，處理時間就是指數據在交換節點中爲存儲轉發而進行一些必要的處理所花費的時間，其中的重要組成部分就是數據在緩衝區隊列中排隊所花費的時間，注意，準確地說應該是「你的數據」在隊列中排隊所花費的時間，由於在隊伍中還有其餘與你絕不相干的數據。此時，若是你想起在介紹帶寬的時候咱們提到的共享帶寬，那就對了。
若是全世界只有你的服務器和你的用戶在傳輸數據，那麼用於排隊的處理時間能夠忽略。可見，處理時間的多少，取決於數據流經各交換節點所在網絡的數據通訊量，它每每是不可預測的，因此它的計算比較複雜，每每沒有一個簡單的數學計算公式，而是依賴於多變的外部因素，必須結合實際狀況具體分析。

那麼，咱們能夠將響應時間的計算公式整理爲：
響應時間 = (數據量比特數 / 帶寬) + (傳播距離 / 傳播速度) + 處理時間另外，下載速度的計算公式以下：
下載速度 = 數據量字節數 / 響應時間
有了以上的計算方法，下面咱們仍是在具體場景中試着來計算響應時間，注意，這裏爲了計算，咱們暫時先忽略處理時間。

咱們的站點用戶毫不可能處於同一個互聯網運營商的網絡中，而事實上即便國內的互聯網能夠高速互聯，若是咱們的站點用戶覆蓋全球，而且要保證高速服務，那麼跨國運營商互聯和國際出口帶寬依然是殘酷存在的問題，幸運的是這些問題均可以抽象爲同類問題來考慮。

歸根結底，但願經過本節的介紹，可讓你們清晰地認識到響應時間和下載速度的本質和計算方法，而至於究竟將服務器部署在哪裏的問題徹底要經過你們本身的考察得出結論，好比選擇IDC的時候要考察出口帶寬以及與骨幹網絡是否直連，若是要同時爲多個互聯網運營商網絡的用戶提供服務，則須要考察出口節點與運營商互聯節點的帶寬，而若是要面向全球用戶提供服務，則須要考察國際網絡結構和各個國家的國際出口帶寬等。另外一方面，帶寬做爲稀缺資源，其價格嚴格服從市場供求規律，好比一樣的獨享帶寬在北京就比瀋陽貴不少，因此咱們在選擇的時候價格因素也至關重要。

2.減小網頁中的http請求

 

將多個圖片合併爲一個文件，利用CSS背景圖片的偏移技術呈如今網頁中，避免了多個圖片的下載。
合併JavaScript腳本或者CSS樣式表。
充分利用HTTP中的瀏覽器端Cache策略，減小重複下載。

 

3.加快服務器腳本計算速度

 

咱們知道，用腳本語言編寫的程序文件須要經過相應的腳本解釋器進行解釋後生成中間代碼，而後依託在解釋器的運行環境中運行。因此生成中間代碼的這部分時間又成爲你們爲獲取性能提高而瞄準的一個目標，對於一些擁有較強商業支持的腳本語言，好比ASP.NET和JSP，均有內置的優化方案，好比解釋器對某個腳本程序第一次解釋的時候，將中間代碼緩存起來，以供下次直接使用。
對於開源類的腳本語言，也有不少第三方組件來提供此類功能，好比PHP的APC組件等。使用這些組件進行腳本優化真的那麼有用嗎？不一樣的應用效果是否有所不一樣呢？

 

4.使用動態類容緩存

 

動態內容技術就像Web開發領域的一場工業革命，它帶來了產業升級和Web開發者的地位提高，在過去至關長一段時間裏，你們廣泛認爲一個站點的技術含量主要體如今後臺的動態程序上，因此不少工程師都會帶着虛榮心警告你：「請叫我後臺開發工程師。」事實上這種概念和偏見已經開始逐漸被歷史拋棄，但這不是咱們此刻討論的重點。
自動態內容技術產生後，聰明的工程師們爲了減小動態內容的重複計算，想到了截取動態內容的勝利果實，將動態內容的HTML輸出結果緩存起來，在隨後的一段時間內當有用戶訪問時便跳太重複的動態內容計算而直接輸出。

在實際應用中，動態內容緩存多是你們使用得最多的技術，可是並不見得全部的動態內容都適合使用網頁緩存，緩存帶來的性能提高偏偏與有些動態數據實時交互的需求造成矛盾，這是很是尷尬的，而解決該問題的惟一途徑不是技術自己，而是你如何權衡。
另外一方面，緩存的實現還涉及了一系列很是現實的問題，即成千上萬的緩存文件如何存儲？緩存的命中率如何？緩存的過時策略如何設計？在擁有多臺Web服務器的分佈式站點上應用動態內容緩存須要考慮什麼呢？

 

5.使用數據緩存

動態內容緩存是將數據和表現總體打包，一步到位，但就像快餐店裏的組合套餐同樣，有時候未必徹底合乎咱們的口味。當咱們意識到在本身的站點中，某些動態內容的計算時間其實主要消耗在一些煩人的特殊數據上，這些數據或者更新過於頻繁，或者消耗大量的I/O等待時間，好比對關係數據庫中某字段的頻繁更新和讀取，這時咱們爲了提升緩存的靈活性和命中率，以及性能的要求，便開始考慮數據緩存。

更加細粒度的數據緩存避免了過時時大量相關網頁的總體更新，好比不少動態內容都包含了一段公用的數據，若是咱們將整個頁面所有緩存，那麼假如這段數據頻繁更新致使頻繁過時，無疑會使得全部網頁都要頻繁地重建緩存，這對網頁的其餘部份內容彷佛很不公平。此時如何協調網頁緩存和數據緩存呢？是否可以將它們一塊兒使用並各顯其能呢？
另外，將數據緩存存儲在哪裏呢？這須要考慮多方面的因素。速度是一方面，若是沒法提供高速的讀寫訪問，那麼這部分數據緩存可能不久便成爲新的系統瓶頸。另外，數據緩存的共享也相當重要，如同一主機上不一樣進程間的共享、網絡上不一樣主機間的共享等，一旦設計不當，將對站點將來的規模擴展帶來致命的威脅。

 

6.動態內容靜態化

在動態內容緩存技術的實現機制中，雖然避免了可觀的重複計算，可是每次還都須要調用動態腳本解釋器來判斷緩存是否過時以及讀取緩存，這彷佛有些多餘，並且關鍵是消耗了很多時間。直接讓瀏覽器訪問這些動態內容的緩存不是更好嗎？在這種狀況下緩存成爲直接暴露給前端的HTML網頁，而整個緩存控制機制也發生了根本的變化，咱們廣泛稱它爲靜態化，靜態網頁獨立了，當家作主了，不再用被腳本解釋器呼來喚去。

7.更快的web服務器軟件

 

從20世紀末開始影響全球經濟的開源軟件，不能否認給咱們的生活帶來了更多豐富的體驗和選擇，可是更多的選擇也表明着更多的結局，不論結局是好是壞，咱們都須要爲此承擔責任。
在Web服務器軟件的選擇問題上，不少架構師依然困惑，大量的壓力測試對比數據蠱惑着激進的開發者和運維工程師，人們只關注所謂的併發量冠軍，卻忽視了更加本質性的東西，甚至不瞭解眼前測試數據的潛在前提。社會老是這樣的，象牙塔式的精英教育和殘酷的淘汰機制斷送了無數人才的將來。而這一次，錯誤的選擇將要付出沉痛的代價。有人拿着所謂的測試數聽說Apache已通過時，你相信嗎？

也許下此結論爲時尚早，儘管放棄它的人比比皆是，可是它的成功不是空穴來風，畢竟它已經活了好久了。
另外一方面，你正在使用的Web服務器軟件也許讓你無比自豪，但是你知道那些複雜的參數配置背後的本質嗎？你知道爲何它僅僅在處理你的站點請求時如此出色嗎？若是讓你本身編寫Web服務器軟件，你可讓它更快一些嗎？
咱們必須中止盲目的選擇，中止對錶面現象的崇拜，咱們須要學習一些稍顯底層的知識來武裝本身。

 

8.頁面組件分離

 

從某種角度看，中學校園裏的快慢分班彷佛合乎邏輯，雖然不必定合乎情理。快班的學生學習能力強，理解知識快，那麼課程安排的節奏能夠加快一些；慢班的學生則能夠放緩課程安排的節奏，這樣既互不影響，學校的升學率又能夠獲得保證，固然假設的前提是學生之間互相幫助效果不大。
在Web站點中，網頁和各類各樣的組件是否也須要「分班」呢？顯然它們的下載量和對服務器的能力要求不盡相同，若是由同一臺物理服務器或者同一種併發策略的Web服務器軟件來統一提供服務，那勢必形成計算資源的浪費以及併發策略的低效。因此，分離帶來的好處是顯而易見的，那就是能夠根據不一樣組件的需求，好比下載量、文件大小、對服務器各類資源的需求等，有針對性地採用不一樣的併發策略，而且提供最佳的物理資源。固然，若是你的站點基本無人問津，並且服務器的各類資源大量閒置，那麼天然不存在什麼性能問題，也不須要什麼組件分離。可是若是你的站點負載已經讓你意識到組件分離是大勢所趨，那仍是趁早動手。

 

9.合理部署服務器

真讓人發瘋，互聯網爲何不是隻有一個，你也許會說難道不是隻有一個Internet嗎？是的，可是Internet所特指的「互聯網」是某種文化意義上的名詞，同一個世界，同一個夢想，同一個互聯網。而我這裏說的互聯網，則是指由某互聯網運營商負責搭建的一系列網絡節點，它覆蓋的地域有大有小，接入這些網絡節點的局域網也能夠相互通訊，同時這些互聯網之間也可以經過骨幹線路互聯互通。

 

世界上不少國家都有不止一個互聯網運營商，中國的互聯網運營商想必你們都很是熟悉，當你在家中安裝寬帶或者須要託管服務器的時候，都面臨着運營商選擇的問題，包括電信、網通、鐵通、移動在內的幾大國內運營商讓你很頭疼。特別是在部署Web站點各種服務器的時候，是否可以找到合理的位置部署服務器相當重要。
咱們都知道，在基於IP尋址的互聯網中，IP地址相近的主機之間通訊，數據通過少數的路由器便可到達，好比同一局域網內通訊或者接入同一個城市交換節點的局域網之間通訊，在這種狀況下數據到達時間相對較短。
而若是通訊的兩端主機位於不一樣運營商的互聯網中，那麼數據必須流經兩個互聯網運營商的頂級交換節點和骨幹線路，在這個過程當中可想而知數據要通過更屢次的存儲轉發，並且各互聯網頂級交換節點之間又存在出口帶寬的限制，若是互聯網之間數據通訊量比較大的話，那麼這個頂級交換節點，也就是「出口」，將會是瓶頸所在，就像鏈接兩座城市之間的高速公路，當大量汽車須要頻繁地往返於兩座城市時，高速公路出現車流緩慢，那麼汽車從一個城市到另外一個城市的整體時間加長了。
顯而易見，咱們固然但願Web站點的用戶和服務器位於同一個互聯網運營商的網絡內，但如何實現呢？

 

10.負載均衡

 

到此爲止，咱們已經最大程度地發揮了單臺Web服務器的處理能力，可是，當它所承受的壓力達到極限時，就須要有更多的服務器來分擔工做，咱們須要想辦法將流量合理轉移到更多的服務器上。
爲此，咱們須要經過各類不一樣的方法來實現Web負載均衡，多是簡單的HTTP重定向，或者是基於DNS的輪詢解析，或者經過反向代理服務器來實現負載均衡調度，還能夠經過LVS來組建服務器集羣，它們有什麼區別呢？不管如何，透過這些具體的實現方法，咱們更加關心的是可否真正地均衡調度請求，以及是否具有高可用性，還有影響規模擴展的制約因素.

 

11.優化數據庫

對於使用數據庫的Web站點來講，你是否在性能優化時或多或少地忽視了數據庫的存在？每每一些性能問題可能都發生在表現不佳的數據訪問層面，這來源於不合理的應用程序數據訪問組件設計、不合理的數據庫表結構設計以及對於數據庫內部構造缺少深刻的瞭解。絕不誇張地說，也許你以前的優化全都白乾了。

Web服務器與數據庫服務器的數據通訊通常基於標準的TCP，即使它們位於同一臺物理主機也是如此。其通訊鏈接的創建和釋放涉及表明一段內核高速緩衝區的文件描述符的建立和銷燬，這須要很多的時間開銷，包括系統調用致使的內核態切換以及某些異步阻塞I/O模型採用的文件描述符隊列掃描機制。因此，頻繁的數據庫鏈接和釋放無疑將致使數據訪問等待時間的加長，這段時間浪費得毫無心義。
使用數據庫持久鏈接有效地解決了這一難題，它包括不一樣程度上的持久化，本質的區別在於持久鏈接的應用範圍和生命週期，好比某個進程內部的全局數據庫鏈接，供進程內全部計算任務共享，在這個進程終止後便被釋放；或者在某個動態內容的執行週期內，代碼層面的持久鏈接對象，在動態內容計算結束後便不復存在；還有跨進程的數據庫鏈接池，保存多個持久鏈接供應用程序重複使用。在這些採用數據庫持久鏈接的應用設計中，同時還要注意保證數據訪問的線程安全性。
與此同時，在設計關係數據庫的表結構時，你是否合理使用了各類類型的索引呢？要作到這一點，你必須瞭解索引的有關知識，然而更重要的是如何根據Web站點變幻莫測的數據訪問特色來有針對性地設計每一個表的索引，這每每也是最有難度的，索引的合理使用對於依賴數據庫訪問的Web應用相當重要。

另外，你瞭解數據庫存儲引擎的特性嗎？其實這並不困難，由於全部的主流數據庫文檔中都有詳細介紹，可是究竟你的Web站點應該選擇什麼存儲引擎呢？固然，沒有絕對完美的方案，咱們在這個世界上要作的惟一的事情就是不斷進行取捨，像考慮索引同樣去弄清楚存儲引擎的本質，是絕對不會讓你失望的。
隨着時間的推移，你的Web站點可能逐漸被數據庫綁架，單臺數據庫服務器再也沒法應付整個站點的須要，這包括存儲空間以及查詢時間，人們開始抱怨數據庫模型的不良設計制約了橫向擴展以及負載均衡，這不是咱們但願看到的結果。爲此，咱們將數據散列在多臺主機，包括必要的冗餘數據，以此來合理地分散數據庫的密集訪問，數據庫擴展便成爲咱們考慮的方案。

 

12.考慮可擴展性

對於Web站點的可擴展性討論已經家常便飯了，不管是代碼層面的擴展，仍是架構層面的擴展，涉及的內容很是多，究竟咱們應該從何談起呢？這是一個值得深思的問題。缺少良好的可擴展性設計就像慢性自殺或者等待死亡，這甚至比Web站點所能遇到的其餘一切困難更讓人頭疼，由於擴展對於咱們來講，就像在山窮水盡的時候被指引了一條星光大道，一旦擴展都沒法進行，那真是死路一條。

的確，可擴展性並非性能和速度的概念，它是指當系統負載增大時，經過增長資源來提升性能的能力。高性能每每須要經過這種能力來實現快速擴展，幾乎沒有多少團隊能夠在一個星期內經過增長服務器立刻讓服務能力擴容100倍。另外一方面，可擴展性的目的在於適應負載的變化，從擴展的技術實現上來看，又包含了不少對局部性能的思考，以及瞭解什麼時候須要擴展，這離不開對站點性能的把握。
然而，就像「人的病都是吃出來的」同樣，Web站點在成長的道路上不斷吸取新的技術，然而每一次技術的應用不當，均可能引入必定程度上的不可擴展。但現實每每是矛盾的，咱們不得不使用一些技術來構建Web站點，同時又使用一些技術來提高站點性能，這些技術構成了咱們理想架構的一部分，關鍵在於在這些技術和架構的應用中，咱們是否意識到可擴展性，而且可否正確評估可擴展性的需求。

 

13.減小視覺等待

 

實在不行就給用戶一些提示吧！最後我只能這麼說了，事實上，這不是什麼大不了的事情，即便認識到架構的瓶頸並投入大量人力來改善，也不是一天兩天就能夠完成的，要意識到用戶也許只是但願你不要不理他而已。
這部分顯然已經超出了本書的討論範圍，它涉及人機交互的相關知識，而且充滿着人文情懷，要真正作好它，恐怕要比本書中全部的問題都更有難度和挑戰性，這絕不誇張，咱們要認可這個現實，由於世界上最難的學問就是研究人，你以爲呢？

引用自《構建高性能web站點》