本文以及接下來的兩篇文章會討論一些性能優化相關的知識，分為上、中、下三個部分。第一部分討論性能分析的基礎內容，第二部分討論實際的性能分析、調優及測試，第三部分討論虛擬化環境和雲計算環境下的性能。文章內容來自於閱讀《圖解性能優化》一書的相關筆記和知識整理以及自己的理解。 轉在此處自己對於本書的豆瓣書評 ...
本文以及接下來的兩篇文章會討論一些性能優化相關的知識，分為上、中、下三個部分。第一部分討論性能分析的基礎內容，第二部分討論實際的性能分析、調優及測試，第三部分討論虛擬化環境和雲計算環境下的性能。文章內容來自於閱讀《圖解性能優化》一書的相關筆記和知識整理以及自己的理解。
轉在此處自己對於本書的豆瓣書評。
作者給出的是一種總攬大局的思維觀念，而並非詳細的性能解決方式。它只是提供了一些角度去考慮性能問題，怎樣排查性能問題，怎樣解決的途徑和突破點可能在何處。書中的示例也並非適用於所有的架構，但可以類比相似的解決方案到其他系統。如果事先沒有對網路知識有一定瞭解，就不能理解在網路過程中存在的性能瓶頸，對操作系統的內在結構不熟悉，也就無法體會中斷處理、鎖機制等等對性能開銷帶來的影響。所以工程應用的解決方案往往是科學問題，這些是計算系統架構的底層和基礎。
《圖解性能優化》重在圖解，但同所有的圖解類圖書一般，圖雖淺顯但也局限。只是更容易去理解一種思路，並不能帶來知識體系的豐富。對於硬體性能的優化，也沒有機會去實踐。作為軟體開發人員，也給了一種全局觀察整個架構的機會。方法是次要的，基礎扎實可以創造方法，書是引路人，只是讓我們走得更容易些。對於經驗豐富的工程師而言，經驗已經融入血液，遇到問題可以四兩撥千斤，迅速定位。作者能給出淺顯的經驗和解決方式是很棒的，軟技能也存在與書中很多地方，能講出來已經是讀者的一種幸運。——@Rainy
性能的基礎知識
性能問題的發生往往歸結於軟體問題和硬體問題兩個方面。這裡的軟體問題是指“應用服務”軟體，深入到軟體的核心，是各種演算法帶來的性能差距。經典演算法和數據結構已經非常成熟，由軟體造成的性能表現不佳也極可能是對演算法應用的不合理。各種演算法都有其相應的適用場景，對演算法數據結構優缺點的把握則是設計良好軟體和架構的基礎。而演算法也並非完全適應與某一個場景，重要的是“折中”思維。性能問題往往都是速度和成本的權衡，演算法也亦然。例如索引可以加快查找速度，但少量查找時又顯得多餘，預見到未來查找的增加，進行數據索引還是有必要的過程。下麵來簡要概述與性能有關的一些演算法及優缺點：
性能與演算法
| 演算法 | 優點 | 缺點 | 改進變種 |
|---|---|---|---|
| 數組O(n) | 善於迴圈處理，按序存放、查找數據 | 未知數組長度，浪費記憶體空間，數據增多時修改不易 | 數組的數組，用一個數組來添加位置變數 |
| 鏈表O(n) | 管理容易變化的數據，增刪數據方便 | 需要訪問動態計算的地址，無法直接同數組下標般找到位置，只能遍歷 | 雙向鏈表 |
| 樹O(logn) | 隨數據增加複雜度增加緩慢，查找範圍逐漸縮小 | 數據更新不便，刪除數據造成空位，影響性能，導致索引碎片化 | n叉樹、B樹、B+樹、B*樹 |
| 散列演算法O(1) | 消除數據的不平衡，直接查找 | 相同數據、相同散列值出現碰撞 | 以鏈表結構連接，“重散列” |
| 隊列O(1) | 大量處理，先入隊列，分割事務（緩衝） | 隊列溢出的情況 | 數組連接的環形結構的隊列，用樹結構實現快速查找的隊列 |
| 棧O(1) | 只占用必要空間，無碎片 | 適用情況少 | 棧軌跡，以棧形式展現函數調用 |
| 快速排序O(nlogn) | 加快查找時間，瞭解重覆情況 | 對頻繁查找有價值，對少量查找則費時間 | 歸併排序 |
| 緩存（回寫） | 不用等待寫入延時 | 可能導致緩存丟失時出現數據不一致現象 | 非易失性(Non-volatile)、電池備份來解決數據丟失 |
| 緩存（直寫） | 數據較快地讀取和寫入 | 響應變慢 | 關機緩存步驟，DBMS日誌實時寫入 |
鎖與性能
鎖機制是為保護數據的完整性及保證數據同步而存在於並行處理中的一種方式，而當鎖出現了鎖等待，則會形成請求隊列。造成請求堆積而導致性能下降，所以需要減少鎖等待的發生。
對 DB 而言，提高對錶加鎖的 SQL 處理速度，可以儘快釋放鎖。或對行加鎖來並行執行，就可以通過分割鎖的方式來減少等待時間。
響應與吞吐
考慮性能時，響應與吞吐是兩個重要的概念。響應是應答快慢，而吞吐是處理數量。有的系統偏重於響應，而有的偏重於吞吐。通過升級硬體來提高響應速度，一般也會提高吞吐，但升級不是無限的，有它的瓶頸和上限。吞吐不夠時，增加響應只是增加了空轉的硬體，並不能解決問題。所以當出現性能問題時，要判斷是響應問題還是吞吐問題，對症下藥。
性能分析的基礎
要進行性能分析首先要進行性能測量，找出問題所在。而性能測量也就是性能分析的原則，首先要從時間和位置兩個角度考慮，也就是“分段查找”的思想。從時間角度是測量某個時間段內的性能信息來進行分析，而位置角度則是測量可能發生性能問題的位置進行定點測量，各個擊破。並且在測量過程中，也要考慮性能測量工具的負載對系統的影響。避免對性能信息進行誤判。
作者將性能信息分為三類：
- 概要形式。獲得的是某段時間內的平均值，適合快速掌握初步信息。
- 事件記錄形式。獲得的是“某時某刻誰做了什麼”之類的詳細信息，對系統壓力較大。不適合經常在生產環境中使用。
- 快照形式。記錄某一瞬間的信息，適合查找引起性能問題的原因。
三類信息獲得之後進行結合分析，來找出問題所在。而獲取三類信息的相應工具和命令，會在下麵給出。
等待隊列理論
在性能方面，“等待隊列理論”具有很強的代表性。首先，隊列中的等待時間稱為“訪問等待時間”，有如下關係：
響應時間 = 訪問等待時間 + 服務時間
等待隊列可以表示為"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 命令可以根據性能信息的分類如下：
- 獲取概要信息：
sar, vmstat, netstat, iostat, profiler - 獲取快照信息：
ps, netstat, top, pstack - 事件記錄形式的信息：
數據包轉儲程式, strace
Windows
Windows 的性能信息工具往往隱藏在控制面板的各個角落，比較有用的有任務管理器、性能監視器、資源監視器等。
關於性能優化的基礎部分談到這裡，第二部分將會談到實際的性能優化、分析及調優。
