主要使用查看結果樹，聚合報告。
查看結果樹：要勾選‘僅日志錯誤’，只顯示錯誤日志。
測試用例，盡可能保持簡單。不能加定時器，除非要加集合點，可以使用Synchronizing Timer。
控制器：可以使用簡單控制器（放有序執行的測試用例），隨機順序控制器（放無序執行的測試用例），其他控制器不要用。盡量少用For each，循環控制器，因為並發數不好控制,避免對並發數產生影響。
前置、后置處理器：盡量不要使用。尤其不能使用BeanShell。除非必須要使用。正則提取器不會產生太大的性能影響。
斷言：盡量不要用斷言，要用的話，推薦使用響應斷言，不推薦用BeanShell斷言。
聚合報告：主要看Average(平均響應時間，保證盡可能短), Error（保證不能出錯）, Throughput（吞吐量，是否達到期望值，也就是TPS-每秒處理的事務數）。
吞吐量的變化在聚合報告中看不出來，要用其他插件。聚合報告中最終的吞吐量是不准的。要用后面講到的集中圖表來分析。
錯誤率也是非常重要，一旦出現錯誤了，說明服務器出現壓力了，瓶頸了，需要進行分析了。（當然首先要保證功能測試沒有錯誤，功能測試沒有問題，才可以進行性能測試）。功能測試沒有錯誤了，做性能測試Error不應該出現。如果出現了，說明服務器在高並發的情況下，出現壓力了，達到瓶頸了。比如說連接超時了，拒絕連接了。
如果沒有插件，主要看結果樹，聚合報告，做以上這些就夠了。
線程：
線程組
設置線程啟動，增加，減少，停止的規則。增加/減少線程盡量不要太快。就是圖中的曲線坡度不要陡，才能保證性能測試的數據比較准確。
性能測試用到的圖：
http://jmeter-plugins.org/wiki/
Active Threads Over time
線程數的變化，X軸是執行時間，Y軸是線程數，和stepping thread group 中配置的線程數圖標類似。
Transactions Throughput vs Threads
Transactions Throughput vs Threads
吞吐量的評估值，X軸是線程數，評估值是不准的。線程數急劇變化的時候（比如線程數108到120時間，有個突然上升到4000的點，是不准的），吞吐量評估值都是不太准的。
50到70個線程數時，吞吐量是比較准的。
65個線程數時，吞吐量最大：
結合Active Threads Over time, 知道65個線程數大概時間是在40到43秒之間：
Transactions per Second
每秒的事務量。這是實際的吞吐量。如果寫測試報告，要寫吞吐量的話，要從多個維度分析。主要看Transactions per Second，不能只看聚合報告的最終吞吐量。（這是不准的）
這和通過Transactions Throughput vs Threads和Active Threads Over time2者結合分析出來的時間是吻合的（40到43秒，吞吐量最大）。
是因為這段時間線程數增加比較快
Connection Times Over Time
連接時間，一般在幾毫秒，不超過5毫秒是理想的。盡量不能讓連接時間達到幾十毫秒，這是網絡問題太大了。這個圖是用來排除網絡問題的。比如某個時間點吞吐量下降厲害了，要去看這個時間點的連接時間是否正常，如果連接時間很長，就是網絡問題造成的，不能判斷為性能問題。
Response Latencies Over Time/Response Times Over Time
響應延遲時間和響應時間基本上是一樣的。
響應延遲時間：發起請求到接口開始響應的時間。
如果Transactions per Second每間隔一定時間，就到達一個頂點（這個頂點），並且每次到達一個頂點的時間都是在線程數增加的時候（結合Active Threads Over time），說明線程數還能再增加，繼續增加測試的線程數：
