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