1. 測試真實的應用程式 1.1. 應該以實際產品的使用方式進行測試 1.2. 所有的基準測試通常都包括一個預熱期，在這期間，JVM可以將代碼編譯到最佳狀態 1.3. 微基準測試（microbenchmark） 1.3.1. 通過測量一小部分代碼的性能來確定多種實現中哪個最好 1.3.2. 必須讀取 ...
1. 測試真實的應用程式
1.1. 應該以實際產品的使用方式進行測試
1.2. 所有的基準測試通常都包括一個預熱期，在這期間，JVM可以將代碼編譯到最佳狀態
1.3. 微基準測試（microbenchmark）
-
1.3.1. 通過測量一小部分代碼的性能來確定多種實現中哪個最好
-
1.3.2. 必須讀取測試的結果
-
1.3.2.1. 從局部變數改為實例變數（用volatile關鍵字進行聲明）即可測量這個方法的性能
-
1.3.2.2. 即使微基準測試是單線程的，也需要使用volatile變數
-
-
1.3.3. 必須測試一系列的輸入值
- 1.3.3.1. 最好提前算好輸入值
-
1.3.4. 必須測量正確的輸入值
- 1.3.4.1. 捕獲異常
-
1.3.5. 代碼在生產環境中可能有不同表現
-
1.3.5.1. 對於不那麼頻繁的操作，修複微基準測試發現的納秒級別的回歸問題就會浪費時間，將這些時間用於優化其他操作必然更有益
-
1.3.5.2. 若一個集合被訪問上百萬次，那麼每次訪問節省的幾納秒就很重要
-
-
1.3.6. 必須包含一個預熱期，讓編譯器有機會生成最佳代碼
-
1.3.6.1. 必須有預熱期，否則它測量的就是編譯性能，而不是代碼性能
-
1.3.6.2. Java的一個性能特點是，代碼執行得越多，性能就越好
-
1.4. 巨集基準測試（macrobenchmark）
-
1.4.1. 要測量一個應用程式的性能，最好的測量對象就是應用程式本身，外加它使用的任何外部資源
-
1.4.2. 資源分配
-
1.4.3. 在沒測試整個應用程式的時候，不可能知道優化哪部分的性能會有效果
1.5. 介基準測試（mesobenchmark）
-
1.5.1. 介於微基準測試和巨集基準測試之間
-
1.5.2. 比微基準測試的缺陷更少，也比巨集基準測試更容易操作
-
1.5.3. 更容易使用多線程
-
1.5.4. 比完整的應用程式更有可能遇到同步瓶頸
-
1.5.5. 介基準測試的性能特點比微基準測試的更接近實際應用程式
-
1.5.6. 用介基準測試進行自動化測試也是很好的方法，特別是在模塊級別的測試中
2. 理解吞吐量、批處理和響應時間
2.1. 測量批處理時間
2.2. 測量吞吐量
-
2.2.1. 基於一定時間內可以完成的工作量
-
2.2.2. 每秒事務數（TPS）
-
2.2.3. 每秒請求數（RPS）
-
2.2.4. 每秒操作數（OPS）
-
2.2.5. 吞吐量測試幾乎都是在適當的預熱期之後進行的
2.3. 響應時間
-
2.3.1. 從客戶端發送請求到收到響應之間的時間
-
2.3.2. 在響應時間測試中，客戶端線程會在操作之間有一段休眠時間，這被稱為思考時間
-
2.3.3. 周期時間（並不是思考時間）
-
2.3.4. 平均響應時間
- 2.3.4.1. 將單個時間加在一起，再除以請求數
-
2.3.5. 百分位響應時間
- 2.3.5.1. 舉例，如果90%的響應小於1.5秒，10%的響應大於1.5秒，那麼1.5秒就是第90百分位響應時間
-
2.3.6. 平均響應時間和百分位響應時間的區別
-
2.3.6.1. 異常值會影響平均值計算。
-
2.3.6.2. 因為在計算平均值時會用到異常值，異常值越大，它對平均響應時間的影響就越大
-
-
2.3.7. 優化重點應該是降低異常值的影響（從而縮短平均響應時間）
-
2.3.7.1. GC引入的暫停時間會讓Java程式更容易出現異常值
-
2.3.7.2. 通常關註第90百分位響應時間（或者第95百分位響應時間和第99百分位響應時間
-
2.3.7.3. 如果你只能測量一個數字，那麼最好選擇基於百分位響應時間的測試，因為減小這個數字將惠及大多數用戶
-
2.3.7.4. 最好同時測量平均響應時間和至少一個百分位響應時間，這樣你就不會錯過異常值過大的情況了
-
-
2.3.8. 負載生成器
-
2.3.8.1. Faban就是基於Java的開源負載生成器
-
2.3.8.2. Apache JMeter
-
2.3.8.3. Gatling
-
2.3.8.4. Micro Focus LoadRunner
-
