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