讀書筆記4瞬時相應網站的高性能架構

 

1、概述

    性能測試是性能優化的前提和基礎。也是性能優化檢查和度量的標準。不一樣的視角下網站的性能有不一樣的標準，也有不一樣的優化手段

2、性能分類

1. 用戶視覺的性能

過程:用戶狀況à網站通信時間à處理時間à用戶計算機瀏覽器解析

優化手段
經過前端優化手段,經過html樣式話,利用瀏覽器段併發和異步特性,挑戰瀏覽器緩存,使用CDN和反向代理使瀏覽器儘快返回用戶感興趣數據。即便不優化應用程序和架構，也能夠很大程度改善用戶視覺性能

1. 開發人員視覺的性能

   關注應用程序自己及子系統的性能，包括相應延遲，系統吞吐量，併發處理能力，系統穩定行等技術指標。

優化手段:

使用緩存加速數據讀取，使用集羣提升吞吐能力，使用異步消息加快請求響應及實現削峯，使用代碼優化改善程序性能。

1. 運維人員視覺的性能

運維人員更關注基礎設施性能和資源利用率,如帶寬處理能力，

優化手段:

服務器硬件配置，數據中心網絡架構，服務器和網絡帶寬利用率等主要優化手段建設，使用高性價比定製服務器,利用虛擬化技術優化資源利用。

 

3、架構設計中要考慮的核心五要素 
性能、可用性、擴展性、伸縮性、安全性

 

4、網站性能測試

（1）性能測試指標：①響應時間；②併發數；③吞吐量；④性能計數器；

（2）性能測試方法：①性能測試；②負載測試；③壓力測試；④穩定性測試；

（3）性能優化策略：

　　①性能分析：排查一個網站的性能瓶頸和排查一個應用查詢的性能手法基本相同：檢查請求處裏的各個環節日誌，分析那個環節響應時間不合理，超過預期；而後檢查監控數據，分析影響性能的主要因素是內存，磁盤，網絡仍是cpu,是代碼問題仍是架構不合理，或是系統資源不足

②性能優化：Web前端優化，應用服務器優化，存儲服務器優化；

性能優化前的準備

性能的測試指標

響應時間 
應用執行一個操做須要的時間，包括從發出請求開始到收到最後響應數據所須要的時間。響應時間是系統最重要的性能指標，直觀地反映了系統的"快慢"。下表列出了一些經常使用的系統操做須要的響應時間。 

併發數 
系統可以同時處理請求的數目

 

吞吐量 

單位時間內系統處理的請求數量; 如：TPS、QPS（每秒查詢數）,HPS每秒http請求數量 ,PV 頁面訪問,隨着併發數的增大，吞吐量隨着增大； 超過閾值後，併發數繼續增大，吞吐量降低，直到吞吐量降爲0，網站宕機；理解上述3個指標：類比高速公路行車 ,吞吐量就是天天經過的車輛數 ,併發數是正在行駛的車輛 ,響應時間是車速

 

性能計數器

描述服務器或操做系統性能指標的一些數據指標。包括System Load,對象與線程數，內存使用，cpu使用，磁盤與網絡io等指標.這些指標也是性能監控的重要指標。System Load反映系統Cpu正在指向和等待執行的進程數量。

性能測試方法

• 性能測試 
  以預期設定的性能值爲目標，測試是否能知足預期
• 負載測試 
  不斷加壓到安全臨界值
• 壓力測試 
  超過安全負載直到崩潰下的最大負載
• 穩定性測試
  特意環境下。持續運行一段較長時間。

下圖中的橫座標表示消耗的系統資源，縱座標表示系統處理能力（吞吐量）。在開始階段，隨着併發請求數目的增長，系統使用較少的資源就達到較好的處理能力（a～b段），這一段是網站的平常運行區間，網站的絕大部分訪問負載壓力都集中在這一段區間，被稱做性能測試，測試目標是評估系統性能是否符合需求及設計目標；隨着壓力的持續增長，系統處理能力增長變緩，直到達到一個最大值（c點），這是系統的最大負載點，這一段被稱做負載測試。測試目標是評估當系統由於突發事件超出平常訪問壓力的狀況下，保證系統正常運行狀況下可以承受的最大訪問負載壓力；超過這個點後，再增長壓力，系統的處理能力反而降低，而資源消耗卻更多，直到資源消耗達到極限（d點），這個點能夠看做是系統的崩潰點，超過這個點繼續加大併發請求數目，系統不能再處理任何請求，這一段被稱做壓力測試，測試目標是評估可能致使系統崩潰的最大訪問負載壓力。

性能測試反應的是系統在實際生產環境中使用時，隨着用戶併發訪問數量的增長，系統的處理能力。與性能曲線相對應的是用戶訪問的等待時間（系統響應時間），如圖所示。

在平常運行區間，能夠得到最好的用戶響應時間，隨着併發用戶數的增長，響應延遲愈來愈大，直到系統崩潰，用戶失去響應。

性能測試報告

測試結果報告應可以反映上述性能測試曲線的規律，閱讀者能夠獲得系統性能是否知足設計目標和業務要求、系統最大負載能力、系統最大壓力承受能力等重要信息，下表是一個簡單示例。

 

5、Web前端性能優化

（1）瀏覽器訪問優化：

　　①減小http請求：由於http是無狀態的，每次請求的開銷都比較昂貴（須要創建通訊鏈路、進行數據傳輸，而服務器端對於每一個http請求都須要啓動獨立的線程去處理）；減小http的主要手段是合併CSS、合併JS、合併圖片（CSS精靈，利用偏移定位image）；

　　②使用瀏覽器緩存：設置http頭中Cache-Control和Expires屬性；

　　③啓用壓縮：能夠對html、css、js文件啓用Gzip壓縮，能夠達到較高的壓縮效率，可是壓縮會對服務器及瀏覽器產生必定的壓力；

　　④CSS放頁面最上面，JS放頁面最下面：瀏覽器會在下載徹底部CSS以後纔開始對整個頁面進行渲染，所以最好將CSS放在頁面最上面；而瀏覽器在加載JS後會當即執行，有可能會阻塞整個頁面，形成頁面顯示緩慢，所以最好將JS放在頁面最下面；

　　⑤減小Cookie傳輸：一方面，太大的Cookie會嚴重影響數據傳輸；另外一方面，對於某些靜態資源的訪問（如CSS、JS等）發送Cookie沒有意義；

（2）CDN加速：

　　CDN（內容分發網絡）仍然是一個緩存，它將數據緩存在離用戶最近的地方，便於用戶以最快速度獲取數據。即所謂的"網絡訪問第一跳"，以下圖所示：

　　CDN只將訪問頻度很高的熱點內容（例如：圖片、視頻、CSS、JS腳本等訪問頻度很高的內容）進行緩存，能夠極大地加快用戶訪問速度，減小數據中心負載。

（3）反向代理：

　　反向代理服務器位於網站機房，代理網站Web服務器接收Http請求，對請求進行轉發，以下圖所示：

　　反向代理服務器具備如下功能：

　　①保護網站安全：任何來自Internet的請求都必須先通過代理服務器；

　　②經過配置緩存功能加速Web請求：減輕真實Web服務器的負載壓力；

　　③實現負載均衡：均衡地分發請求，平衡集羣中各個服務器的負載壓力；

6、應用服務器性能優化

（1）分佈式緩存：

PS：網站性能優化第必定律：優先考慮使用緩存優化性能。緩存是指將數據存儲在相對較高訪問速度的存儲介質中（如內存），以供系統進行快速處理響應用戶請求。

　　①緩存本質是一個內存Hash表，數據以(Key,Value)形式存儲在內存中。

　　②緩存主要用來存放那些讀寫比很高、不多變化的數據，如商品的類目信息、熱門商品信息等。這樣，應用程序讀取數據時，先到緩存中取，如緩存中沒有或失效，再到數據庫中取出，從新寫入緩存以供下一次訪問。所以，能夠很好地改善系統性能，提升數據讀取速度，下降存儲訪問壓力。

　　③分佈式緩存架構：一方面是以以JBoss Cache爲表明的互相通訊派；另外一方面是以Memcached爲表明的互不通訊派；

　　JBoss Cache須要將緩存信息同步到集羣中的全部機器，代價比較大；而Memcached採用一種集中式的緩存集羣管理，緩存與應用分離部署，應用程序經過一致性Hash算法選擇緩存服務器遠程訪問緩存數據，緩存服務器之間互不通訊，於是集羣規模能夠輕易地擴容，具備良好的伸縮性。

　　Memcached由兩個核心組件組成：服務端（ms）和客戶端（mc），在一個memcached的查詢中，mc先經過計算key的hash值來肯定kv對所處在的ms位置。當ms肯定後，客戶端就會發送一個查詢請求給對應的ms，讓它來查找確切的數據。由於這之間沒有交互以及多播協議，因此 memcached交互帶給網絡的影響是最小化的。

（2）異步操做：

　　①使用消息隊列將調用異步化，可改善網站的擴展性，還可改善網站性能；

　　②消息隊列具備削峯的做用->將短期高併發產生的事務消息存儲在消息隊列中，從而削平高峯期的併發事務；

PS：任何能夠晚點作的事情都應該晚點再作。前提是：這個事兒確實能夠晚點再作。

（3）使用集羣：

　　①在高併發場景下，使用負載均衡技術爲一個應用構建多臺服務器組成的服務器集羣；

　　②能夠避免單一服務器因負載壓力過大而響應緩慢，使用戶請求具備更好的響應延遲特性；

　　③負載均衡能夠採用硬件設備，也能夠採用軟件負載。商用硬件負載設備（例如出名的F5）成本一般較高（一臺幾十萬上百萬很正常），因此在條件容許的狀況下咱們會採用軟負載，軟負載解決的兩個核心問題是：選誰、轉發，其中最著名的是LVS（Linux Virtual Server）。

PS：LVS是四層負載均衡，也就是說創建在OSI模型的第四層——傳輸層之上，傳輸層上有咱們熟悉的TCP/UDP，LVS支持TCP/UDP的負載均衡。

LVS的轉發主要經過修改IP地址（NAT模式，分爲源地址修改SNAT和目標地址修改DNAT）、修改目標MAC（DR模式）來實現。有關LVS的詳情請參考：http://www.importnew.com/11229.html

（4）代碼優化：

　　①多線程：使用多線程的緣由：一是IO阻塞，二是多CPU，都是爲了最大限度地利用CPU資源，提升系統吞吐能力，改善系統性能；

　　②資源複用：目的是減小開銷很大的系統資源的建立和銷燬，主要採用兩種模式實現：單例（Singleton）和對象池（Object Pool）。例如，在.NET開發中，常用到的線程池，數據庫鏈接池等，本質上都是對象池。

　　③數據結構：在不一樣場合合理使用恰當的數據結構，能夠極大優化程序的性能。

1. 垃圾回收：理解垃圾回收機制有助於程序優化和參數調優，以及編寫內存安安全的代碼。這裏主要針對Java（JVM）和C#（CLR）一類的具備GC（垃圾回收機制）的語言。

Java中JVM介紹及GC執行時機

內存分爲堆棧和堆,堆棧用於存儲線程上下文信息，如方法參數，局部變量等。堆則是存儲對象的內存空間，對象的建立和銷燬。垃圾回收就是在這裏進行。

將JVM分爲年輕帶(Young Generation)和年老帶(Old Generation),又將年輕帶(Young Generation)分爲,Eden區,From區,To區。新建對象老是在Eden區建立，當Eden區空間已滿,就觸發一次Young GC(Garbage Collection,垃圾回收),將還被使用的對象複製到From區,這樣Eden區都是未使用的對象,還能夠繼續建立對象,當Eden去在次用完,在觸發一次Young GC,將Eden區和From區還在使用的對象複製到To區。下一次Young GC則是將Eden區和To區對象複製到From區。通過屢次GC,某些對象會在From和To區屢次複製，若是超過某個閥值對象還未被釋放，則將對象複製到Old Generation。若是Old Generation空間已經用完，那麼會觸發Full GC,即所謂的全量回收，全量回收對系統性能產生較大影響，所以應該根據業務特色和對象生命週期合理設置Young Generation和Old Generation區域大小，儘可能減小Full GC.

 

7、存儲性能優化

（1）機械硬盤仍是固態硬盤？

　　①機械硬盤：經過馬達驅動磁頭臂，帶動磁頭到指定的磁盤位置訪問數據。它可以實現快速順序讀寫，慢速隨機讀寫。

　　②固態硬盤（又稱SSD）：無機械裝置，數據存儲在可持久記憶的硅晶體上，所以能夠像內存同樣快速隨機訪問。

　　在目前的網站應用中，大部分應用訪問數據都是隨機的，這種狀況下SSD具備更好的性能表現，可是性價比有待提高（蠻貴的，麼麼嗒）。

（2）B+樹 vs LSM樹

　　①傳統關係型數據庫普遍採用B+樹，B+樹是對數據排好序後再存儲，加快數據檢索速度。

PS：目前大多數DB多采用兩級索引的B+樹，樹的層次最多三層。所以可能須要5次磁盤訪問才能更新一條記錄（三次磁盤訪問得到數據索引及行ID，一次數據文件讀操做，一次數據文件寫操做，終於知道數據庫操做有多麻煩多耗時了）

　　②NoSQL（例如：HBase）產品普遍採用LSM樹：

　　具體思想是：將對數據的修改增量保持在內存中，達到指定的大小限制後將這些修改操做批量寫入磁盤。不過讀取的時候稍微麻煩，須要合併磁盤中歷史數據和內存中最近的修改操做，因此寫入性能大大提高，讀取時可能須要先看是否命中內存，不然須要訪問較多的磁盤文件。

　　LSM樹的原理是：把一棵大樹拆分紅N棵小樹，它首先寫入內存中，隨着小樹愈來愈大，內存中的小樹會被清除並寫入到磁盤中，磁盤中的樹按期能夠作合併操做，合併成一棵大樹，以優化讀性能。

　　LSM樹的優點在於：在LSM樹上進行一次數據更新不須要磁盤訪問，在內存便可完成，速度遠快於B+樹。

8、學習總結

　　對於網站的高性能架構這一章的閱讀，經過大牛的書籍咱們學到了從三個主要方面的性能優化策略，雖然都是理論，並且還只是淺顯地說明，可是對於咱們這些廣大的開發菜鳥來講，擴展知識面，瞭解一點優化策略不是一件壞事，咱們能夠從中注意到平常的代碼規範，如何寫出高效的代碼也是一件值得研究的事兒。在書中，看到了做者寫了這樣一句話，貼出來與各位正在學習途中的菜鳥們共享："歸根結底，技術是爲業務服務的，技術選型和架構決策依賴業務規劃乃至企業戰略規劃，離開業務發展的支撐和驅動，技術走不遠，甚至還會迷路"。出來實習了一年多，對這句話感慨頗多，也吃了不少的虧，在和客戶的溝通交流上也有了本身的一點感悟，因此貼出來與各位園友共勉。最後，但願做爲菜鳥的咱們，在技術這條路上可以走得遠一些，迷路不重要，重要的是可以迷途知返，麼麼嗒！再過一個多月，就要開始找工做了，但願在此期間可以認真閱讀完本身的計劃書單，加油！

參考文獻

（1）李智慧，《大型網站技術架構-核心原理與案例分析》，http://item.jd.com/11322972.html

（2）周言之，《Memcached詳解》，http://blog.csdn.net/zlb824/article/details/7466943

（3）百度百科，CDN，http://baike.baidu.com/view/8689800.htm

（4）王晨純，《Web基礎架構：負載均衡和LVS》，http://www.importnew.com/11229.html

（5）輝之光，《B樹、B-樹、B+樹》，http://www.cnblogs.com/oldhorse/archive/2009/11/16/1604009.html

（6）yanghuahui's blog，《LSM樹由來、設計思想以及應用到HBase的索引》，http://www.cnblogs.com/yanghuahui/p/3483754.html

本章思惟導圖

 

聲明

部份內容轉載自http://www.cnblogs.com/edisonchou/博客