參考《全棧效能測試修煉寶典JMeter實戰》第十五章 JMeter常見問題
1、無法產生負載
注意檢查各元件是否時禁用狀態。JMeter在執行時是以數形式載入各種元件的，如果父節點被禁用，那麼其下的所有子節點將不會執行。雖然下面的子節點沒有被禁用，但執行時根本無法產生負載，但JMeter不會報錯。
2、做介面測試
常見的有HTTP協議、Socket協議、WebSocket協議、Soap協議等，只要構造好表單，在JMeter中用相應的Sampler就可以模擬請求。
3、多個測試計劃執行
在編輯選單欄中有個合併操作，點選後可以將多個測試計劃合成一個，每一個指令碼是一個執行緒組，執行時同時執行執行緒組即可。
4、找導致CPU瓶頸的程式
在效能測試分析時，往往採用自底向上的方式來進行問題分析，我們從硬體的指標來反向追索問題根源。其中CPU的效能瓶頸分析最為常見。
監控CPU使用率，CPU使用率分為系統和使用者的使用率。
系統CPU利用率高可以先關注下IO，有沒有非空閒等待，通常的系統CPU利用高都是IO問題，此時的中斷與切換都高。
使用者CPU利用率高，直接使用top命令檢視系統程式和執行緒，通過執行緒或程式ID可以找到對應的程式。
5、找導致記憶體瓶頸的程式
linux系統可用記憶體包括實體記憶體、快取、程式佔用的記憶體等部分。記憶體瓶頸會導致程式執行緩慢甚至系統崩潰，通過監控記憶體的使用情況發現潛在的效能問題。
6、找導致IO瓶頸的程式
網路IO的監控可以監控網路中斷、頻寬、網路連線數及網路連線狀態，從而確定那方面的瓶頸。
本地磁碟IO可以監控有沒有IO的非空閒等待
7、計算併發使用者數
併發數受到很多因素的影響。比如思考時間、工作時間、業務分佈等，通常技術併發使用者數有三種方式：
由TPS來估算併發數
由TPS來估算，適用於聯機作業系統，這類系統響應時間快、業務量大。
Vu（業務名稱）=TPS（業務名稱）x （RunTime+ThinkTime）
Vu表示此業務的虛擬使用者數，RunTime時測試程式/指令碼執行一次所消耗的時間，包括事務時間和非事務時間
由線上活動使用者數來估算併發數
適合於讀請求多的系統，比如新聞
根據經驗估算
不是一種嚴謹的估算方式。
8、效能測試的分析方法
自底向上：通過監控硬體及作業系統效能指標（CPU、記憶體、磁碟、網路等硬體資源的效能）來分析效能問題（配置、程式等）。因為使用者請求最終是由計算機硬體裝置來完成的。
自頂向下：通過生成負載來觀察被測試的系統效能，比如響應時間、吞吐量，然後從請求起點由外及裡一層一層分析。