【轉載】大型網站效能

weixin_33896726發表於2016-10-23

參考這篇文章:http://www.csdn.net/article/2014-09-30/2821940

把整個過程,分為三段路徑:

  • 第一段在使用者和瀏覽器端,主要負責發出使用者請求,以及接受響應資料進行計算渲染顯示給使用者;
  • 第二段在網路上,負責對請求資料、響應資料的傳輸;
  • 第三段在網站伺服器端,負責對請求資料進行處理(執行程式、訪問資料庫、檔案等),並將結果返回;

 

第一路徑:

輸入域名發起請求,實質過程是:

使用者在瀏覽器輸入要訪問的網站域名;
本地DNS請求網站授權的DNS伺服器對域名進行解析,並得到解析結果即IP地址(並將IP地址快取起來)。
向目標IP地址發出請求。

優化:

從這個過程我們可以看到,優化的地方主要是減少DNS解析次數,而如果使用者瀏覽器設定了快取,則再第二次訪問相同域名的時候就不會去請求DNS伺服器,
直接用快取中的IP地址發出請求。因此這個過程主要取決於瀏覽器的設定。現在主流的瀏覽器預設設定了DNS的預取功能(DNS Prefetch),
當然你也可以主動告知瀏覽器我的網站需要做DNS預取:
<meta http-equiv="x-dns-prefetch-control" content="on" />

 渲染:

瀏覽器將資料進行計算渲染的過程:

瀏覽器解析響應資料;
瀏覽器建立DOM樹;
瀏覽器下載CSS樣式,並應用到DOM樹,進行渲染;
瀏覽器下載JS檔案,開始解析執行;
顯示給使用者。

優化:

從這個過程,我們可以找出不少可以優化的地方。首先我們可以儘量控制頁面大小,使得瀏覽器解析的時間更短;
並且將多個CSS檔案、JS檔案檔案合併壓縮減少檔案下載的次數和大小;另外注意將CSS放在頁面前面,JS訪問頁面後面,
這樣便於頁面首先能渲染出來,再執行js指令碼,對於使用者來說有更好的體驗。最後我還可以設定瀏覽器快取,下次訪問時從快取讀取內容,減少http請求。
<meta http-equiv="Cache-Control" content="max-age=5" /> 該程式碼說明了瀏覽器啟用了快取並在5秒內不會再次訪問伺服器。注意快取的設定需要結合你的業務特性來適當配置。

第二路徑

頻寬

我們知道頻寬速度分為上行、下行速度,也就是上傳和下載的速度。頻寬20M對於使用者來說則是下載速度20M(20×1024×1024位元率),換算成位元組20M/8=2.5M。
也就是說20M的頻寬下載速度理論可達2.5M/s,而對於家庭使用者而言上傳速度一般比下載速度小的多,大約是不到十分之一。
而對於網站伺服器(企業使用者)來說,則不然,一般上行速度等於下載速度。
這也是運營商根據實際需求分配的,畢竟使用者的主要需求是下載資料,而不是上傳資料。

分析

對於使用者來說,上傳資料是很小的(Url引數),而下載資料是較大的(響應資料);
對於伺服器來說,下載資料是很小的(url引數),上傳資料是較大(響應資料)。

理解了這個,我們可以解釋為什麼有時使用者反映為什麼自己的頻寬足夠,但開啟某些網站仍然很慢,
就是因為儘管使用者的下載速度很快,但網站伺服器的上傳速度很慢。

瞭解了這個原理我們來看怎麼提高資料傳輸的速度,首先使用者的上傳、下載速度我們是無法決定的,我們能決定的是網站伺服器的上傳、下載速度,
所以我們可以做的是適當的增加伺服器頻寬(頻寬是很貴的,盲目的增加只會增加不必要成本)。 購買合適的頻寬需要根據網站業務特性、規模以及結合運維人員的經驗來選擇。通常可以考慮的演算法,即根據一次響應資料的大小,乘以PV數,除以對應的高峰時間段,
從而大致估算出網站頻寬的需求。 下圖表示使用者訪問網站伺服器時網路的大致情況,從圖上可以看出假設網站伺服器從電信網路接入。 而使用者A作為電信的寬頻使用者,則可以通過電信骨幹網快速的訪問到網站伺服器。使用者B,使用者C作為移動和聯通使用者需要通過運營商的互聯互通經過較長路徑才能訪問到伺服器。

優化:

針對這種情況,我們可以採取以下方法來優化:

1. 在各運營商發達的地區的IDC(網際網路資料中心,可以理解成機房)部署網站伺服器,各運營商的使用者即可通過各自的骨幹網訪問伺服器。
2. 購買代理服務,也就是原來聯通使用者需要通過聯通骨幹網——
>聯通互聯互通路由器——>電信骨幹網——>網站伺服器的過程。
通過代理服務,代理伺服器直連到電信骨幹網,
訪問網站伺服器。
3. 在主要地區城市購買CDN服務,快取對應的資料,使用者可先從最近的CDN運營商獲取請求資料。

第三路徑

第三路徑主要是網站伺服器內部處理的過程,當中包括執行程式、訪問檔案、資料庫等資源。

這是對於我們來說最可以發揮的地方:

使用快取,根據需要使用本地快取或分散式快取;
使用非同步操作,這種方式不僅可以提高效能,也提高了系統的擴充套件性;
程式碼優化;
儲存優化;

快取  Redis/Memcached

非同步操作 

如下圖,使用同步請求的方式,在高併發的情況下,會對資料庫造成很大的壓力,也會讓使用者感覺響應時間過長。
非同步請求方式,則可以快速的對使用者做出響應,而具體的資料庫操作請求,則通過訊息佇列伺服器傳送給資料庫伺服器,做具體的插入操作。
插入操作的結果則已其他方式通知客戶端。例如一般在訂票系統當中,出票行為就是非同步完成,最終的出票結果會以郵件或其他方式告知使用者。

程式碼優化

http://www.cnblogs.com/leefreeman/p/3585032.html (後面會另開一文記錄讀書筆記)

儲存優化

磁碟陣列、分散式儲存、flash硬碟

效能的指標和測試

響應時間、併發量、吞吐量

響應時間:就是使用者發出請求到收到響應資料的時間;
併發量:就是系統同時能處理多少使用者請求;
吞吐量:就是單位時間內系統處理的請求數量;

之間的關係,下面這張圖描述得挺好:

小結

三個路徑過程。各自主要優化點。三個重要指標。 

 

相關文章