之前很少做性能測試，經過兩周的奮戰，終於拿出了一份報告。過程坎坷，記錄以備忘。
1、jmeter java請求，記得在finally代碼塊中調用SampleResult.sampleEnd()，否則測試時無響應時間。
2、YOUNG GC頻率比較高，調整啟動參數，加大堆初始內存 -Xms4096m
3、存儲過程的效率。自己寫的存儲過程，半個小時才插入20萬數據；經開發優化后，不到5分鍾插100萬條！！！
存儲過程，不要嵌套類似這樣的查詢，否則效率很低。 insert into table_name1 values ((select id from table_name2 where xxx), value2, value3 )
4、查詢接口的測試，要考慮db中表的數據量
5、往db插測試數據的時候，時間字段盡量要隨機，不要CURRENT_TIMESTAMP()，否則如果查詢接口按時間段查詢，30秒間隔會返回很多數據，測試結果失真
6、分頁查詢，效率會隨着offset增大而大幅降低。40並發，把24核的物理機CPU干到95%，太可怕！找dba排查，定位到是分頁查詢問題，把接口入參的limit和頁數減小，CPU下去了，TPS是之前的三倍。當然查詢語句也有問題，select * from table_name1 where id in (select id from table_name2 where xxx)這種語句也很慢
7、jdk/bin下，有很多的性能監控用的小工具
8、關注壓力機的CPU和內存使用率，有時候是壓力機性能瓶頸，導致服務性能指標上不去
9、測試報告不要只是堆疊數據表格，主要是突出性能場景、性能分析、問題匯總、優化建議等
10、在新機器上配置環境，部署服務很費時間；由於是新機器，會出現N多問題，工作量評估的時候要考慮到
11、並發量很大，TPS上不去，響應時間比較長，而且app服務器和db服務CPU/內存都沒上去。響應時間長，可能是db連接池過小，導致線程等待時間長。
把線程池從10~50，改成100~200后，響應時間縮短一半，在高並發的時候。