Web應(yīng)用，本質(zhì)是各種Web內(nèi)容從Web網(wǎng)站達(dá)到瀏覽器，呈現(xiàn)給用戶。用戶希望在獲取Web內(nèi)容的時(shí)間越短越好。從Web網(wǎng)站的角度，需要解決大量用戶并發(fā)訪問時(shí)的時(shí)延問題，體現(xiàn)為兩大度量指標(biāo)：吞吐量和并發(fā)度。吞吐量指單位時(shí)間內(nèi)能完成請(qǐng)求數(shù)（req/s）。并發(fā)度指同時(shí)發(fā)起請(qǐng)求的客戶端數(shù)量（瀏覽器發(fā)送請(qǐng)求有一定的并發(fā)度，例如能同時(shí)發(fā)送4個(gè)請(qǐng)求，在這里算4個(gè)客戶端）。在一定的并發(fā)度下，吞吐量越大，客戶感覺的時(shí)延就越低，網(wǎng)站的性能就越高。

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

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

改進(jìn)服務(wù)器IO并發(fā)模型。有三種經(jīng)典IO并發(fā)模型：進(jìn)程并發(fā)、線程并發(fā)、事件并發(fā)。在這三種模型中，事件并發(fā)是最輕量級(jí)的，因?yàn)槎鄠€(gè)事件在單個(gè)線程中處理，大大減少了線程切換時(shí)間，并節(jié)省內(nèi)存。所以采用事件并發(fā)模型的NginX/Lighttpd能承受的并發(fā)程度最高。

緩存網(wǎng)站內(nèi)容。有兩種情況：1）緩存動(dòng)態(tài)內(nèi)容的靜態(tài)結(jié)果，加速動(dòng)態(tài)內(nèi)容；2）在靠客戶較近的地方緩存網(wǎng)站內(nèi)容，節(jié)省帶寬。

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

加速數(shù)據(jù)庫訪問。有幾種手段：1）增加分布式緩存，緩存查詢結(jié)果；2）建索引；3）增加DBMS內(nèi)部查詢緩存；4）DBMS內(nèi)部緩存索引和數(shù)據(jù)。后兩項(xiàng)可通過數(shù)據(jù)庫配置進(jìn)行。

增加網(wǎng)絡(luò)帶寬。如果網(wǎng)絡(luò)帶寬成為瓶頸，適當(dāng)增加網(wǎng)絡(luò)帶寬。

邏輯架構(gòu)如下圖所示。

不同的Web內(nèi)容，因?yàn)樘匦圆煌?#xff0c;性能瓶頸往往也不同，所需的Web加速策略也不一樣。

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

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

• 靜態(tài)內(nèi)容（視頻）。視頻內(nèi)容往往很大，但用戶不追求最高的下載速度，只要能趕上播放速度就行。但是視頻延續(xù)時(shí)間長，從統(tǒng)計(jì)學(xué)角度看所需帶寬很大；而且現(xiàn)在的高清視頻，單路視頻對(duì)帶寬要求也很大。所以就近部署的緩存服務(wù)器是常有的選擇。

• 動(dòng)態(tài)內(nèi)容。瓶頸在動(dòng)態(tài)計(jì)算和數(shù)據(jù)庫，一般實(shí)施下列策略：1）緩存opcode；2）加速數(shù)據(jù)庫訪問；3）對(duì)更新不頻繁的動(dòng)態(tài)內(nèi)容，利用緩存服務(wù)器或Web瀏覽器緩存靜態(tài)化后的內(nèi)容。動(dòng)態(tài)內(nèi)容靜態(tài)化后往往表現(xiàn)出驚人的并發(fā)性能提升效果。

充分考慮網(wǎng)站的內(nèi)容特征，靈活應(yīng)用上述加速策略，就能降低服務(wù)器/帶寬成本，獲得最高性價(jià)比。

轉(zhuǎn)載于:https://blog.51cto.com/cangfu/1574445

與50位技術(shù)專家面對(duì)面20年技術(shù)見證，附贈(zèng)技術(shù)全景圖

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。