1.1 性能問題的現狀
傳統軟件開發流程java
傳統開發流程與添加了性能測試流程的開發過程的區別，建議作法：算法
- 性能測試是否經過設定爲是否可以發佈的一個標準
- 性能分析貫穿於分析（詳細設計/erd設計）、設計、編碼的流程中
- 在自動化構建和測試中添加必要的自動化性能測試，並將結果以郵件方式發送給干係人，對於不達標的測試，將不達標的測試和測試數據自動錄入缺陷管理系統
- 將統計方法和自動統計分析添加到自動化性能測試系統（第8章詳細講解）
將性能測試加入到傳統的軟件開發流程中。應用的性能需求如何挖掘，下面以吞吐量和延遲性爲需求須要考慮的問題：編程
- 應用預期的吞吐量是多少？
- 請求和響應之間的延遲預期是多少？
- 應用支持多少併發用戶或併發任務？
- 當併發用戶數或併發任務數量達到最大時，可接受的吞吐量和延遲是多少？
- 最差狀況下延遲是多少？
- 要使垃圾收集引入的延遲在可容忍的範圍內，垃圾收集的頻率應該是多少？
需求文檔中應可以對應以上問題，並以此制定基準測試和性能測試，確保應用可以知足性能和擴展性需求。緩存
1.2 性能分析的兩種方法：自頂向下和自底向上
1.2.1 自頂向下：着眼於軟件棧頂層的應用代碼的更改和使用，從上往下尋找優化的機會和問題
自頂向下的第一步老是對應用進行監控，監控的內容包括：操做系統、Jaa虛擬機、JavaEE容器以及應用的性能測量指標。多線程
基於監控的結果再開展下一步操做，下一步操做例如：JVM垃圾收集器調優、JVM命令行選項調優、操做系統調優等架構
1.2.2 自底向上：從軟件棧底層（如CPU指令效率、CPU高速緩存）開始，逐漸上升級到應用自身的結構或應用常見的使用方式。
自頂向下和自底向上能夠用來查詢和解決不一樣類型的性能問題。併發
自底向上的常見分析方法：jvm
- 遷移應用到其餘操做系統（不改變源代碼）
- 將應用部署到不一樣的運行環境中
- 更改jvm版本，生成更有效的機器碼
- 更改操做系統的設置，如：操做系統等待時間（cpu切換調度時間）
計算機存儲結構工具
CPU Cache的簡單示意圖性能
| 從CPU到 | 大約須要的CPU週期 | 大約須要的時間(單位ns) |
| 寄存器 | 1 cycle | |
| L1 Cache | ~3-4 cycles | ~0.5-1 ns |
| L2 Cache | ~10-20 cycles | ~3-7 ns |
| L3 Cache | ~40-45 cycles | ~15 ns |
| 跨槽傳輸 | ~20 ns | |
| 內存 | ~120-240 cycles | ~60-120ns |
1.3 選擇正確的平臺並評估系統性能
1.3.1 選擇正確的cpu架構
cpu架構的概念：CPU架構是CPU廠商給屬於同一系列的CPU產品定的一個規範，主要目的是爲了區分不一樣類型CPU的重要標示。目前市面上的CPU分類主要分有兩大陣營，一個是intel、AMD爲首的複雜指令集CPU，另外一個是以IBM、ARM爲首的精簡指令集CPU。兩個不一樣品牌的CPU，其產品的架構也不相同，例如，Intel、AMD的CPU是X86架構的，而IBM公司的CPU是PowerPC架構，ARM公司是ARM架構。
- 多線程不必定比單線程執行的更快，由於線程切換須要時間
- 上下文切換次數和時長的測試工具：lmbench3（檢測時間）、vmstat（檢測次數）
- 減小上下文切換的方法：
- 協程：在單線程裏實現多任務的調度，並在單線程裏維持多個任務間的切換
- 使用最少線程：避免建立沒必要要的線程，任務較少時，多餘的線程會處於等待狀態
- CAS算法，java的Atomic包使用CAS算法來更新數據，而不須要使用鎖
- 無鎖併發編程：例如將數據按照必定的算法進行取模分段，不一樣的線程處理不一樣段的數據
1.3.2 評估系統性能
- cpu切換時間
- cpu高速緩存命中