Web應用，本質是各種Web內容從Web網站達到瀏覽器，呈現給用戶。用戶希望在獲取Web內容的時間越短越好。從Web網站的角度，需要解決大量用戶并發訪問時的時延問題，體現為兩大度量指標：吞吐量和并發度。吞吐量指單位時間內能完成請求數（req/s）。并發度指同時發起請求的客戶端數量（瀏覽器發送請求有一定的并發度，例如能同時發送4個請求，在這里算4個客戶端）。在一定的并發度下，吞吐量越大，客戶感覺的時延就越低，網站的性能就越高。

不同的并發度下，網站的吞吐量并不是一個常量。一般來說，當并發度小于某個閾值時，網站能保持相對穩定的吞吐量；而超過這個閾值，網站的吞吐量則迅速下降。這個閾值決定于網站的消息處理速度。假設網絡帶寬不是瓶頸，請求消息達到網站后，被緩存在內核的緩沖區隊列，然后被并行處理。當網站處理消息的速度趕不上消息緩沖的速度時，隊列中消息就會大量堆積，導致處理時延迅速增加，吞吐量迅速下降。在通常的壓力測試模型中，一般模擬多個用戶并行發送消息，某個用戶接受收到上一消息的回應后，才會發下一個消息。所以如果網站消息處理時延延長，消息發送間隔自然延長，單位時間內涌向網站的消息減少，這會導致網站吞吐量下降，從而在一個新的吞吐量下達成消息處理與消息到達的平衡。但在真實的場景中，在訪問高峰期，性急的用戶會不斷刷新瀏覽器，涌向網站的請求消息量持續超過網站的實際處理能力，請求被大量堆積在網站的緩沖區，直至網站的內存耗盡，導致網站癱瘓。所以，真實場景中為避免網站癱瘓，要采取流量控制措施。

為了加速WEB網站，提升WEB性能，一般有下列措施：

改進服務器IO并發模型。有三種經典IO并發模型：進程并發、線程并發、事件并發。在這三種模型中，事件并發是最輕量級的，因為多個事件在單個線程中處理，大大減少了線程切換時間，并節省內存。所以采用事件并發模型的NginX/Lighttpd能承受的并發程度最高。

緩存網站內容。有兩種情況：1）緩存動態內容的靜態結果，加速動態內容；2）在靠客戶較近的地方緩存網站內容，節省帶寬。

加速動態內容計算。對CPU密集型的動態腳本，緩存opcode，不要每次都解析原始腳本。服務器腳本解析器運行緩存的OpCode，比直接解析原始腳本，效率要高很多。這也是為什么PHP/Python解析引擎需要把原始腳本編譯成OpCode，然后再通過虛擬機來解析執行的原因，這樣就可以達到和Java、C#差不多的性能。多一道轉換，根本原因是為了提升性能。

加速數據庫訪問。有幾種手段：1）增加分布式緩存，緩存查詢結果；2）建索引；3）增加DBMS內部查詢緩存；4）DBMS內部緩存索引和數據。后兩項可通過數據庫配置進行。

增加網絡帶寬。如果網絡帶寬成為瓶頸，適當增加網絡帶寬。

邏輯架構如下圖所示。

不同的Web內容，因為特性不同，性能瓶頸往往也不同，所需的Web加速策略也不一樣。

• 靜態內容（小文件）。例如各種圖片內容，所需的帶寬相對較小。網站處理的瓶頸在IO并發。因此可選用支持事件并發模型的輕量級Web服務器，如NginX/Lighttpd。同時為避免頻繁的TCP建立和連接，可打開HTTP協議的KeepAlive長連接功能。這樣就存在大量空閑連接，需開啟epoll并發模型。同時對更新不頻繁的內容，可利用HTTP協議的Last-Modified?/?If-Modified-Since，ETag?/?If-None-Match，Expires?/?Cache-Control等頭域協商，在瀏覽器緩存器內容。

• 靜態內容（大文件）。例如各種下載資源，所需帶寬大。此時瓶頸往往在帶寬，可在靠近客戶的地域部署緩存服務器，緩存服務器的緩存策略同樣遵守HTTP的頭域協商。

• 靜態內容（視頻）。視頻內容往往很大，但用戶不追求最高的下載速度，只要能趕上播放速度就行。但是視頻延續時間長，從統計學角度看所需帶寬很大；而且現在的高清視頻，單路視頻對帶寬要求也很大。所以就近部署的緩存服務器是常有的選擇。

• 動態內容。瓶頸在動態計算和數據庫，一般實施下列策略：1）緩存opcode；2）加速數據庫訪問；3）對更新不頻繁的動態內容，利用緩存服務器或Web瀏覽器緩存靜態化后的內容。動態內容靜態化后往往表現出驚人的并發性能提升效果。

充分考慮網站的內容特征，靈活應用上述加速策略，就能降低服務器/帶寬成本，獲得最高性價比。

轉載于:https://blog.51cto.com/cangfu/1574445

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的谈谈Web加速的全部內容，希望文章能夠幫你解決所遇到的問題。

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