最近乙個專案快上線了，用的是springcloud微服務，資料庫是mysql，持久層是mybatis，測試在進行效能壓測的時候，有乙個微服務的介面一壓就掛，於是領導安排我去優化。我看了效能單，30多萬的資料量，50的併發介面就掛掉了。
1、首先了解介面**，裡面並沒有複雜的業務邏輯，是乙個普通的分頁查詢，根據前台傳入的引數查詢出結果，對結果進行了一次遍歷判斷，然後新加乙個字段。最後返回前台。用的是pagehelper外掛程式進行的分頁。然後檢視sql語句，就是:select * from info_table where park_code = '10034' and incident_level = 'a' order by open_date 。看了下日誌列印有問題，入參日誌在controller層列印了，在service層又列印相同的日誌，而且最不合理的是將結果集一股腦列印出來，果斷去掉。
2、**了解了之後先簡單判斷，最大的問題估計就是出在查詢上面，把查詢語句拿出來單獨執行了下，1.42秒。檢查表索引，發現索引都加上了。然後是pagehelper外掛程式，網上了解一下，它是字段sql拼接limit，大部分人表示效能很慢，而且給出了建議。於是按照建議進行嘗試，不再使用pagehelper，自己手動分頁，修改查詢語句，select a.* from info_table as a inner join (select id from info_table where park_code = '10034' and incident_level = 'a' order by open_date limit 1, 10) on b where a.id = b.id; 執行一下300多毫秒，比以前快了1秒多。修改完成之後，使用jmeter本地壓測，併發100，壓測時間10分鐘，介面正常，查詢引數第1頁，3000頁，31000頁，平均響應時間1.26秒，1.46秒，1.78秒。於是把**部署到伺服器。想著這樣也就差不多了，把**部署上去，然後等著測試去壓測。
3、本以為就此告一段落，結果第二天測試告訴我結果說伺服器上面100併發壓測居然要5.74秒，還是不達標，這下就不淡定了，居然還這麼慢，不過好在不會出現介面壓掛的事情，說明大方向沒錯，然後對**再次進行了解析，只剩下乙個遍歷的邏輯了，按理來說分頁查詢出來的資料也就10條，遍歷判斷一下，然後在結果集裡面增加乙個字段應該是很快的，仔細看下這個遍歷到的業務邏輯，詢問了下當時做這個介面的開發人員，說是這個是開發完之後加的，要求根據時間判斷一下資料是否為新資料，增加乙個標識讓前台展示。雖然很好奇為什麼前端在展示的時候不能直接判斷一下就好，非得我們後台多此一舉給它增加乙個字段，但事已至此也沒辦法，於是把這個判斷挪到sql裡面，在sql 裡面增加乙個case when 語句，於是sql 就變成這樣 select a.*，case when open_date > date_add(now(), interval -5 minute) then 1 else 0 end as is_new from info_table as a inner join (select id from info_table where park_code = '10034' and incident_level = 'a' order by open_date limit 1, 10) on b where a.id = b.id；測試結果比上次快了700多毫秒，平均響應時間在5秒以內，勉強達標。
4、後面分析：本地與測試相差這麼多，估計記憶體佔了大部分，然後free -m 檢視下記憶體，top檢視下佔記憶體最高的那個，ps -ef | grep 檢視下，發現記憶體引數最大2g，啟動就佔了1.5g，jstat -gcutil 檢視下gc記錄，發現在壓測的時候ygc很頻繁，10分鐘內22次，平均一次0.7秒多，fgc一次。設定xmn引數可能是個選擇，適當可以增加下記憶體。也可以使用memory analysis tool工具具體分析下記憶體的使用情況，這裡就不做太多的說明了。
介面效能調優記錄
最近專案需要效能調優 1.使用postman新增響應時間200ms測試用例 2.逐個測試，找出有效能問題的介面，單個調優 3.在方法裡加入時間戳或者stopwatch，找出有效能問題的 4.一般都是sql優化，執行計畫看下是否走了索引，沒有就加下索引，大的sql看看能否拆成小的 5.優化，可以使用多...
調優 Nginx效能調優
一.nginx優化配置 1.主配置檔案優化 注 部分配置詳解 worker processes 8 nginx程序數，建議按照cpu數目來指定，一般為它的倍數。worker cpu affinity 00000001 00000010 00000100 00001000 00010000 00100...
Spark效能調優 JVM調優
通過一張圖讓你明白以下四個問題 1.jvm gc機制，堆記憶體的組成 2.spark的調優為什麼會和jvm的調優會有關聯？因為scala也是基於jvm執行的語言 3.spark中oom產生的原因 4.如何在jvm這個層面上來對spark進行調優 補充 spark程式執行時 jvm堆記憶體分配比例 r...