簡談性能優化（上）

本文以及接下來的兩篇文章會討論一些性能優化相關的知識，分爲上、中、下三個部分。第一部分討論性能分析的基礎內容，第二部分討論實際的性能分析、調優及測試，第三部分討論虛擬化環境和雲計算環境下的性能。文章內容來自於閱讀《圖解性能優化》一書的相關筆記和知識整理以及本身的理解。

轉在此處本身對於本書的豆瓣書評。

做者給出的是一種總攬大局的思惟觀念，而並不是詳細的性能解決方式。它只是提供了一些角度去考慮性能問題，怎樣排查性能問題，怎樣解決的途徑和突破點可能在何處。書中的示例也並不是適用於全部的架構，但能夠類比類似的解決方案到其餘系統。若是事先沒有對網絡知識有必定了解，就不能理解在網絡過程當中存在的性能瓶頸，對操做系統的內在結構不熟悉，也就沒法體會中斷處理、鎖機制等等對性能開銷帶來的影響。因此工程應用的解決方案每每是科學問題，這些是計算系統架構的底層和基礎。

《圖解性能優化》重在圖解，但同全部的圖解類圖書通常，圖雖淺顯但也侷限。只是更容易去理解一種思路，並不能帶來知識體系的豐富。對於硬件性能的優化，也沒有機會去實踐。做爲軟件開發人員，也給了一種全局觀察整個架構的機會。方法是次要的，基礎紮實能夠創造方法，書是引路人，只是讓咱們走得更容易些。對於經驗豐富的工程師而言，經驗已經融入血液，遇到問題能夠四兩撥千斤，迅速定位。做者能給出淺顯的經驗和解決方式是很棒的，軟技能也存在與書中不少地方，能講出來已是讀者的一種幸運。——@Rainy

性能的基礎知識

性能問題的發生每每歸結於軟件問題和硬件問題兩個方面。這裏的軟件問題是指「應用服務」軟件，深刻到軟件的核心，是各類算法帶來的性能差距。經典算法和數據結構已經很是成熟，由軟件形成的性能表現不佳也很可能是對算法應用的不合理。各類算法都有其相應的適用場景，對算法數據結構優缺點的把握則是設計良好軟件和架構的基礎。而算法也並不是徹底適應與某一個場景，重要的是「折中」思惟。性能問題每每都是速度和成本的權衡，算法也亦然。例如索引能夠加快查找速度，但少許查找時又顯得多餘，預見到將來查找的增長，進行數據索引仍是有必要的過程。下面來簡要概述與性能有關的一些算法及優缺點：

性能與算法

算法	優勢	缺點	改進變種
數組O(n)	善於循環處理，按序存放、查找數據	未知數組長度，浪費內存空間，數據增多時修改不易	數組的數組，用一個數組來添加位置變量
鏈表O(n)	管理容易變化的數據，增刪數據方便	須要訪問動態計算的地址，沒法直接同數組下標般找到位置，只能遍歷	雙向鏈表
樹O(logn)	隨數據增長複雜度增長緩慢，查找範圍逐漸縮小	數據更新不便，刪除數據形成空位，影響性能，致使索引碎片化	n叉樹、B樹、B+樹、B*樹
散列算法O(1)	消除數據的不平衡，直接查找	相同數據、相同散列值出現碰撞	以鏈表結構鏈接，「重散列」
隊列O(1)	大量處理，先入隊列，分割事務（緩衝）	隊列溢出的狀況	數組鏈接的環形結構的隊列，用樹結構實現快速查找的隊列
棧O(1)	只佔用必要空間，無碎片	適用狀況少	棧軌跡，以棧形式展示函數調用
快速排序O(nlogn)	加快查找時間，瞭解重複狀況	對頻繁查找有價值，對少許查找則費時間	歸併排序
緩存（回寫）	不用等待寫入延時	可能致使緩存丟失時出現數據不一致現象	非易失性(Non-volatile)、電池備份來解決數據丟失
緩存（直寫）	數據較快地讀取和寫入	響應變慢	關機緩存步驟，DBMS日誌實時寫入

鎖與性能

鎖機制是爲保護數據的完整性及保證數據同步而存在於並行處理中的一種方式，而當鎖出現了鎖等待，則會造成請求隊列。形成請求堆積而致使性能降低，因此須要減小鎖等待的發生。

對 DB 而言，提升對錶加鎖的 SQL 處理速度，能夠儘快釋放鎖。或對行加鎖來並行執行，就能夠經過分割鎖的方式來減小等待時間。

響應與吞吐

考慮性能時，響應與吞吐是兩個重要的概念。響應是應答快慢，而吞吐是處理數量。有的系統偏重於響應，而有的偏重於吞吐。經過升級硬件來提升響應速度，通常也會提升吞吐，但升級不是無限的，有它的瓶頸和上限。吞吐不夠時，增長響應只是增長了空轉的硬件，並不能解決問題。因此當出現性能問題時，要判斷是響應問題仍是吞吐問題，對症下藥。

性能分析的基礎

要進行性能分析首先要進行性能測量，找出問題所在。而性能測量也就是性能分析的原則，首先要從時間和位置兩個角度考慮，也就是「分段查找」的思想。從時間角度是測量某個時間段內的性能信息來進行分析，而位置角度則是測量可能發生性能問題的位置進行定點測量，各個擊破。而且在測量過程當中，也要考慮性能測量工具的負載對系統的影響。避免對性能信息進行誤判。

做者將性能信息分爲三類：

1. 概要形式。得到的是某段時間內的平均值，適合快速掌握初步信息。
2. 事件記錄形式。得到的是「某時某刻誰作了什麼」之類的詳細信息，對系統壓力較大。不適合常常在生產環境中使用。
3. 快照形式。記錄某一瞬間的信息，適合查找引發性能問題的緣由。

三類信息得到以後進行結合分析，來找出問題所在。而獲取三類信息的相應工具和命令，會在下面給出。

等待隊列理論

在性能方面，「等待隊列理論」具備很強的表明性。首先，隊列中的等待時間稱爲「訪問等待時間」，有以下關係：

響應時間 = 訪問等待時間 + 服務時間

等待隊列能夠表示爲"M/M/1"。分別表示請求到達時間的特徵，服務時間的特徵，處理的並行程度（1 指線性處理）。由於請求是徹底隨機的，因此出現短暫的大量請求，也會產生等待隊列。

假設處理時間是 1 秒，每小時處理的條數是 3000 條。

ρ(平均使用率) = [1(處理時間)×3000(處理條數)]/3600(單位時間) = 0.83
等待時間/1秒 = 0.83/（1-0.83）= 4.88
響應時間 = 4.88(等待時間)+1(處理時間)

由上面的式子能夠看出，當平均使用率增長的時候，等待時間呈指數級別增長。

在 CPU 使用率的統計工具中，有時能夠看到尖峯的出現。頻繁的尖峯出現每每是系統出現問題的前兆，但少數尖峯的出現是容許存在的，使用超線程能夠改善此現象。然而在批處理中不該該存在這樣的狀況，處理時間久也不會致使等待隊列的變長，因爲不能經過等待隊列的狀況來判斷性能問題，這時就應判斷單個處理器的時間長度了。

當調查引發性能問題的緣由時，須要肯定一些必要的檢測信息。而對於須要得到哪些信息，並無統一的標準。須要按照實際狀況去確認。

獲取性能信息的 OS 命令

對於獲取性能信息的方式，須要瞭解一些得到信息的 OS 命令。對於 Linux 主要經過內置的命令來得到，Windows 大都是獲取相應信息的圖形化界面。此外有時還須要其餘的工具或軟件，例如對網絡進行性能分析時，須要使用 Wireshark 來進行抓包分析。下面簡要介紹相關命令，具體使用可查閱相關手冊（提供的是得到信息的方式和思路，而非詳細的使用和操做步驟）。

Linux

對於 Linux 而言，獲取性能信息的 OS 命令能夠根據性能信息的分類以下：

1. 獲取概要信息：

   sar, vmstat, netstat, iostat, profiler

2. 獲取快照信息：

   ps, netstat, top, pstack

3. 事件記錄形式的信息：

   數據包轉儲程序, strace

Windows

Windows 的性能信息工具每每隱藏在控制面板的各個角落，比較有用的有任務管理器、性能監視器、資源監視器等。

---

關於性能優化的基礎部分談到這裏，第二部分將會談到實際的性能優化、分析及調優。