當經歷了無數的日日夜夜，朝九晚九，攻克了無數難關，終於將系統預定功能開發完成，通過測試，部署上線後。你是否會感覺志得意滿，到達了人生巔峰，高唱無敵是多麼寂寞。
現實情況是，如果你這個系統，業務沒有做起來，沒啥人用，huan則罷liao。如果有越來越多的人，持續使用。隨著使用者增多，業務資料增多，那系統一定會暴露一些效能問題。而對這些問題的優化解決，以及監測，往往需要比開發具體功能，更高更全面的技術素質及能力。
一、效能問題監控
鍋叔雲：效能問題是具有隱蔽效能，伺服器硬體效能良好不等於系統服務效能良好。這麼說可能經驗欠缺的同學難於理解。不就是系統慢麼，使用者會告訴我們啊？ 我們有伺服器監控啊，如果cpu，或者記憶體滿了，會有監控報警啊？
首先，系統慢使用者未必會告訴你，如果比你的競品慢太多，使用者會用腳投票。然後，如果你開發的系統在把硬體跑到瓶頸之前都快如閃電，請收下鍋叔的膝蓋-_-|| 。
常見的效能問題，往往是欠缺效能考慮引起的，響應巨慢的同時，硬體利用率可能5%不到，這類問題也是此次鍋叔主要討論的。
經驗上來說，對於效能問題的監控預警是難於解決具體的效能問題的。實踐中我們需要一些日常機制來篩查系統效能問題，避免病入膏肓。
資料庫慢查詢日誌——是一個重要的監控途徑，其中記錄了耗時較長的資料庫操作記錄。可以通過手動或自動分析慢查詢日誌，篩查可能存在的效能問題，主流資料庫都支援慢查詢日誌生成，具體的配置方式此處不做贅述。非統計類的資料操作通常應該在100ms以下。
介面效能監控——後臺系統通常是通過服務介面向外提供服務的，前端頁面或者移動裝置是通過呼叫服務端介面來完成對應操作的。介面的粒度是大於資料庫操作的，一個介面呼叫可能包含很多個資料庫呼叫。介面效能更接近於使用者體驗，因為多數時候使用者的一個操作動作會對應一個服務介面（如儲存，確認）。在不存在慢查詢的時候，介面效能可能也會不滿足要求，可能的原因如，一個介面迴圈呼叫了1000次資料庫操作，或者呼叫了一些第三方介面等。對介面的效能監測原理上就是用呼叫結束的時間減去進入的時間點計算總耗時，並把這個耗時記錄下來，以便時候篩查。Spring的切片能力可以方便的實現該需求。非報表，匯出類介面，鍋叔認為應當在1秒內完成為佳。
訊息佇列——如果你的系統中使用到了類似訊息佇列的機制，對佇列中排隊的訊息數，同樣應當進行監測，訊息如果發生了堆積，說明在這個階段內，系統的整體消費能力已經不能滿足輸出要求了。
以上三個監控維度是互不重疊的，應該同時進行。
二、效能問題的定位
除了資料庫慢查詢日誌可以明確提示具體SQL緩慢外，上面另外兩種情況所能直接提示定位到的粒度都比較大，對應一個介面或者一段處理過程程式碼。
定位更細問題的具體方法也很容易想到，即分段輸出各階段的耗時。如對於一個100行的方法，可以在第30，60，100，分別計算並日志輸出這3段執行耗費的時間。重複進行，就最終可以定位到將問題所在。
效能問題的定位需要有一些效能常識，所謂效能常識即，通常做一件事情需要完成的時間，不用很準確，但量級要清楚。比如一次資料庫操作，一般在數十毫秒，與記憶體的互動在納秒或者微秒間，與第三方系統的介面可能在數百毫秒到幾秒之間。有了這些經驗我們才能夠對耗時是否合理有個基本判斷。比如對於一個50毫秒的資料庫操作，迴圈100次就是5秒，已經很慢了，可以考慮是不是可以合併成一次批量操作。
三、應用效能優化方法
合併遠端呼叫——根據經驗，實踐中因為迴圈進行資料庫操作，或對第三方系統介面進行迴圈呼叫，是引起效能問題的非常非常常見的原因。對於此類問題的優化方式通常就是優化呼叫的方式，使用批量操作。例如，如果需要去資料庫中查詢鍋叔近一年的打卡記錄，可以用準確日期，查詢365次，也可以用時間範圍一次查詢出365條，後面的方法肯定比前面的快很多。如果方法比較複雜，冗長，可以從中抽取所需的公共資料，進行統一的批量查詢取出，放入記憶體備用，會比哪裡用到哪裡查要快很多。同樣寫入，修改操作，也儘量批量進行。
使用快取——對於訪問頻率較高的資料，可以在記憶體中儲存，利用記憶體存取要快於硬碟很多的特性，來進行訪問加速。常見的場景如各種計數——鍋叔的文章有多少次瀏覽之類。
多執行緒並行——通過多執行緒把序列修改為並行。例如與裝置通訊查詢狀態，逐個查詢和並行同時向裝置查詢，後者要快得多。現實中多數的操作耗時是在IO上，因此多執行緒方式可以有效提高效能，避免“空”等。多執行緒並行需要注意做好執行緒同步。
四、資料庫效能優化
資料庫是一個現代系統都會依賴的元件，對他的效能問題解決也是開發人員需要掌握的。
增加索引——加索引，是資料庫優化的首選方案。原理是利用空間換時間。現在儲存的成本下降非常快，基本上可以做到常規業務資料查詢都可以走索引。對於複雜的sql 有時需要分析下怎麼加索引，可以通過執行計劃來分析。
鎖等待——資料庫是有鎖概念的，一個事務佔有X鎖未提交前，其他事務是不能夠對該記錄進行操作的，只能等待。未使用唯一索引的資料庫寫操作，可能會對全表加寫鎖，在提交前，全表記錄無法操作。因此對資料庫鎖，應當有所認識，儘量晚上鎖，儘快解鎖，儘量小範圍上鎖。推論可得，實踐中，如果是長事務，儘量把更新操作後移，把耗時的非事務性操作（如無依賴的第三方介面等），設法從事務中移除。
事務隔離級別——選擇合適的事務隔離級別，事務隔離級別與資料庫鎖有關，如最嚴格的序列隔離級別，所有的事務將序列進行。廣泛使用的資料庫MYSQL，其預設隔離級別為"可重複讀"，但帶來了間隙鎖的限制，增加了鎖搶佔的概率。如無特別，可以根據實際情況調整為“讀提交”
中間結果——本質可以理解為資料庫層次的快取，如果一些結果從全量記錄中計算資料量巨大，耗時必然很長。可以分批計算，儲存中間結果。以加速資料取得。如計算鍋叔家近一年的總支出，可以通過每筆記錄加起來，也可以每個月算一次，這樣只需要查詢近12個月的支出加起來就可以啦。