**1. 性能** [TOC] ## 1.1 監控指標 在系統并發數由小逐漸增大的過程中(這個過程也伴隨著服務器系統資源消耗逐漸增大)，系統吞吐量先是逐漸增加，達到一個極限后，隨著并發數的增加反而下降，達到系統崩潰點后，系統資源耗盡、吞吐量為零。 而這個過程中，響應時間則是先保持小幅上升，到達吞吐量極限后，快速上升，到達系統崩潰點后，系統失去響應。 ### 1.1.1 響應時間 `響應時間`：指應用執行一個操作需要的時間（從發出請求開始到收到最后響應數據所需的時間）。是系統最重要的性能指標，直觀地反映了系統的“快慢”。 :-: 常用系統操作響應時間表  ### 1.1.2 并發數 `并發數`：指系統能同時處理的請求數目。對于網站而言，即是指網站的并發用戶數（同時提交請求的用戶數目）。 >[info] 網站系統用戶數 >> 網站在線用戶數 >> 網站并發用戶數 ### 1.1.3 吞吐量 `吞吐量`：指單位時間內系統處理的請求數量，體現系統的整體處理能力。 * TPS（每秒事務數），是吞吐量的常用量化指標。 * QPS（每秒查詢數） * HPS（每秒HTTP請求數） ### 1.1.4 性能計數器 * System Load：系統負載 >[] 指當前正在被CPU執行和等待被CPU執行的進程數總和，是反映系統忙閑程度的重要指標。 * 對象與進程數 * 內存使用 * CPU使用 * 磁盤I/O * 網絡I/O 上述指標也是系統監控的重要參數，對這些指標設置報警閾值，當監控系統發現性能計數器超過閾值時，就向運維和開發人員報警，及時發現處理系統異常。 **多核CPU的System Load** * 完美情況是，所有CPU 都在使用，沒有進程在等待處理，所以Load的理想值是CPU的數目。 * 當Load值低于 CPU數目的時候，表示CPU有空閑，資源存在浪費； * 當Load值高于CPU數目的時候，表示進程在排隊等待CPU調度，表示系統資源不足，影響應用程序的執行性能。 在Linux系統中使用`top`命令查看，System Load是三個浮點數，表示最近1分鐘，5分鐘，15分鐘的運行隊列平均進程數，如下圖所示。  :-: Linux命令行查看系統負載 ## 1.2 性能測試 ### 1.2.1 響應時間 測試程序通過模擬應用程序，記錄收到響應和發出請求之間的時間差來計算系統響應時間。 實踐中通常采用的辦法是重復請求，比如一個請求操作重復執行一萬次，測試一萬次執行需要的總響應時間之和，然后除以一萬，得到單次請求的響應時間。 ### 1.2.2 并發數 測試程序通過多線程模擬并發用戶的辦法來測試系統的并發處理能力。 為了真實模擬用戶行為，測試程序并不是啟動多線程然后不停地發送請求，而是在兩次請求之間加入一個隨機等待時間， 這個時間被稱作思考時間。 ### 1.2.3 測試方法 `性能測試`是一個不斷對系統增加訪問壓力，以獲得系統性能指標、最大負載能力、最大壓力承受能力的過程。 所謂的增加訪問壓力， 在系統測試環境中，就是不斷增加測試程序的并發請求數。一般說來，性能測試遵循下圖所示的拋物線規律。  :-: 性能測試曲線 上圖中的a~b段是系統的`日常運行區間`，系統使用較少的資源就達到較好的處理能力。 上圖中c點是系統的`最大負載點`。超過這個點后，再繼續加大并發請求數，系統的處理能力反而下降，而資源的消耗更多，直到資源消耗達到極限（d點）。 d點是系統的`崩潰點`。超過這個點繼續加大并發請求數，系統不能再處理任何請求。 `用戶訪問的等待時間`：性能測試反應的是系統在實際生產環境中使用時，隨著用戶并發訪問數量的增加，系統的處理能力。 與性能曲線相對應的是用戶訪問的等待時間 ( 系統響應時間)，如下圖所示。  :-: 并發用戶訪問響應時間曲線 在日常運行區間（a~b），系統可以獲得最好的用戶響應時間，但隨著并發用戶數的增加，響應延遲越來越大，直到系統崩潰，用戶失去響應。  :-: 性能測試結果報告 ## 1.3 性能分析 如果性能測試結果不能滿足設計或業務需求，那么就需要尋找系統瓶頸，分而治之，逐步優化。 大型網站結構復雜，用戶從瀏覽器發出請求直到數據庫完成操作事務，中間需要經過很多環節，如果測試或者用戶報告網站響應緩慢，存在性能問題，必須對請求經歷的各個環節進行分析，排查可能出現性能瓶頸的地方,定位問題。 * **性能分析方法**： 排查一個網站的性能 瓶頸和排查一個程序的性能瓶頸的手法基本相同： 1. 檢查請求處理的各個環節的日志，分析哪個環節響應時間不合理、超過預期； 2. 然后檢查監控數據，分析影響性能的主要因素是內存、磁盤、網絡、還是CPU，是代碼問題還是架構設計不合理，或者系統資源確實不足。 ### 1.3.1 前端（用戶角度） 用戶在瀏覽器上直觀感受到的網站響應速度的快慢。 **用戶感受到的時間：** * 用戶計算機和網站服務器通信時間 * 網站服務器處理的時間 * 用戶計算機瀏覽器購置請求數據的時間 * 用戶計算機瀏覽器解析響應數據的時間  **優化方法：** 1. 盡可能快地顯示用戶感興趣的內容 * 優化頁面HTML式樣、 * 利用瀏覽器的并發和異步特性、 * 調整瀏覽器的緩存策略 2. 盡可能近地獲取頁面內容 * 使用CDN服務 * 使用反向代理 ### 1.3.2 應用程序、編碼（開發人員角度） **優化方法：** 1. 使用`緩存`加速數據讀取 2. 使用`集群`提高吞吐能力 3. 使用`異步`消息加快請求響應和實現削峰 4. 使用`代碼優化`手段改善程序性能。 ### 1.3.3 運維（運維人員角度） **優化方法：** 1. 建設優化骨干網。 2. 使用高性價比定制服務器。 3. 利用虛擬化技術優化資源利用。 ### 1.3.4 性能優化的目的 * 改善用戶體驗 * 減少用戶操作的響應時間 * 盡量提高系統吞吐量 * 最大限度利用服務器資源 ## 1.4 性能優化 根據網站分層架構，可分為web前端、應用服務器、存儲服務器性能優化3大類 ### 1.4.1 web前端 1. 瀏覽器訪問優化 * 減少http請求 * 使用瀏覽器緩存 * 啟用壓縮 * CSS放在網頁最上面，JavaScript放網頁最下面 * 減少Cookie傳輸 2. CDN加速 3. 反向代理 ### 1.4.2 應用服務器 1. 分布式緩存 * `JBoss Cache`：需要更新同步 * `Memcached`：不互相通信，豐富客戶端程序（Java、php、Perl、Python、Ruby、C/C++/C#），海量數據可伸縮 2. 異步操作 3. 使用集群 4. 代碼優化 * 多線程。保證線程安全的編碼手段：將對象設計為無狀態對象；使用局部變量；并發訪問資源時使用鎖。 * 資源復用。單例（Singleton）；對象池（Object Pool） * 數據結構。Hash表；字符串Hash散列算法（Time33） * 垃圾回收。JVM的堆（heap）和堆棧（stack）。堆空間又分為Young Generation/Old Generation ### 1.4.3 存儲服務器 在網站應用中，海量的數據讀寫對磁盤訪問造成巨大壓力，雖然可以通過 Cache解決一部分數據讀壓力，但是很多時候，磁盤仍然是系統最嚴重的瓶頸。而且磁盤中存儲的數據是網站最重要的資產，磁盤的可用性和容錯性也至關重要。 1. 機械硬盤 2. 固態硬盤（SSD） 3. B+樹 `B+樹`：傳統關系型數據庫常使用的數據結構。是一種專門針對磁盤存儲而優化的N叉排序樹。 4. LSM樹 `LSM樹`：NoSQL數據庫常使用的數據結構。可看作是一個N階合并樹。 5. RAID 在傳統關系型數據庫及文件系統中應用較為廣泛。 6. HDFS（Hadoop File System） HDFS配合MapReduce等并行計算框架進行大數據處理時，可以在整個集群上并發讀寫訪問所有磁盤，無需RAID支持。