性能測試：系統(tǒng)架構性能優(yōu)化思路
今天談下業(yè)務系統(tǒng)性能問題分析診斷和性能優(yōu)化方面的內容。這篇文章重點還是談已經上線的業(yè)務系統(tǒng)后續(xù)出現性能問題后的問題診斷和優(yōu)化重點。
系統(tǒng)性能問題分析流程
我們首先來分析下如果一個業(yè)務系統(tǒng)上線前沒有性能問題，而在上線后出現了比較嚴重的性能問題，那么實際上潛在的場景主要來自于以下幾個方面。
業(yè)務出現大并發(fā)的訪問，導致出現性能瓶頸 上線后的系統(tǒng)數據庫數據日積月累，數據量增加后出現性能瓶頸 其它關鍵環(huán)境改變，比如我們常說的網絡帶寬影響
正是由于這個原因，當我們發(fā)現性能問題的時候，首先就需要判斷是單用戶非并發(fā)狀態(tài)下本身就有性能問題，還是說在并發(fā)狀態(tài)才存在性能問題。對于單用戶性能問題往往比較容易測試和驗證，對于并發(fā)性能問題我們可以在測試環(huán)境進行加壓測試和驗證，以判斷并發(fā)下的性能。
如果是單用戶本身就存在性能問題，那么大部分問題都出在程序代碼和SQL需要進一步優(yōu)化上面。如果是并發(fā)性能問題，我們就需要進一步分析數據庫和中間件本身的狀態(tài)，看是否需要對中間件進行性能調優(yōu)。
在加壓測試過程中，我們還需要對CPU，內存和JVM進行監(jiān)控，觀察是否存在類似內存泄漏無法釋放等情況，即并發(fā)下性能問題本身也可能是代碼本身原因導致性能異常。
性能問題影響因素分析
對于性能問題影響因素，簡單來說包括了硬件環(huán)境，軟件運行環(huán)境和軟件程序三個方面的主要內容。下面分別再展開說明下。
硬件環(huán)境
硬件環(huán)境就是我們常說的計算，存儲和網絡資源。
對于服務器的計算能力，一般來說廠家都會提供TPMC參數作為一個參考數據，但是我們實際看到相同TPMC能力下的X86服務器能力仍然低于小型機的能力。
除了服務器的計算能力參數，另外一個重點就是我們說的存儲設備，影響到存儲的重點又是IO讀寫性能問題。有時候我們監(jiān)控發(fā)現CPU和內存居高不下，而真正的瓶頸通過分析反而發(fā)現是由于IO瓶頸導致，由于讀寫性能跟不上，導致大量數據無法快速持久化并釋放內存資源。
比如在Linux環(huán)境下，本身也提供了性能監(jiān)控工具方便進行性能分析。比如常用的iostat,ps,sar,top,vmstat等，這些工具可以對CPU，內存，JVM，磁盤IO等進行性能監(jiān)控和分析，以發(fā)現真正的性能問題在哪里。
比如我們常說的內存使用率持續(xù)告警，你就必須發(fā)現是高并發(fā)調用導致，還是JVM內存泄漏導致，還是本身由于磁盤IO瓶頸導致。
對于CPU，內存，磁盤IO性能監(jiān)控和分析的一個思路可以參考：
運行環(huán)境-數據庫和應用中間件
數據庫和應用中間件性能調優(yōu)是另外一個經常出現性能問題的地方。
數據庫性能調優(yōu)
拿Oracle數據庫來說，影響數據庫性能的因素包括：系統(tǒng)、數據庫、網絡。數據庫的優(yōu)化包括：優(yōu)化數據庫磁盤I/O、優(yōu)化回滾段、優(yōu)化Rrdo日志、優(yōu)化系統(tǒng)全局區(qū)、優(yōu)化數據庫對象。
要調整首先就需要對數據庫性能進行監(jiān)控
我們可以在init.ora參數文件中設置TIMED_STATISTICS=TRUE 和在你的會話層設置ALTER SESSION SET STATISTICS=TRUE 。運行svrmgrl 用 connect internal 注冊，在你的應用系統(tǒng)正常活動期間，運行utlbstat.sql 開始統(tǒng)計系統(tǒng)活動，達到一定的時間后，執(zhí)行utlestat.sql 停止統(tǒng)計。統(tǒng)計結果將產生在report.txt 文件中。
數據庫性能優(yōu)化應該是一個持續(xù)性的工作，一個方面是本身的性能和參數巡檢，另外一個方面就是DBA也會經常提取最占用內存的低效SQL語句給開發(fā)人員進一步分析，同時也會從數據庫本身的以下告警KPI指標中發(fā)現問題。
比如我們可能會發(fā)現Oracle數據庫出現內存使用率高的告警，而通過檢查會發(fā)現是產生了大量的Redo日志導致，那么我們就需要從程序上進一步分析為何會產生如此多的回滾。
應用中間件性能分析和調優(yōu)
應用中間件容器即我們常說的Weblogic, Tomcat等應用中間件容器或Web容器。應用中間件調優(yōu)一個方面是本身的配置參數優(yōu)化設置，一個方面就是JVM內存啟動參數調優(yōu)。
對于應用中間件本身的參數設置，主要包括了JVM啟動參數設置，線程池設置，連接數的最小最大值設置等。如果是集群環(huán)境，還涉及到集群相關的配置調優(yōu)。
對于JVM啟動參數調優(yōu)，往往也是應用中間件調優(yōu)的一個關鍵點，但是一般JVM參數調優(yōu)會結合應用程序一起進行分析。
其中JVM啟動的主要控制參數說明如下:
-Xmx??#設置最大堆空間
-Xms??#設置最小堆空間
-XX:MaxNewSize?#設置最大新生代空間
-XX:NewSize????#設置最小新生代空間
-XX:MaxPermSize??#設置最大永久代空間(注：新內存模型已經替換為Metaspace)
-XX:PermSize?????#設置最小永久代空間(注：新內存模型已經替換為Metaspace)
-Xss???#設置每個線程的堆棧大小
Java整個堆大小設置，Xmx 和 Xms設置為老年代存活對象的3-4倍，即FullGC之后的老年代內存占用的3-4倍。永久代 PermSize和MaxPermSize設置為老年代存活對象的1.2-1.5倍。
年輕代Xmn的設置為老年代存活對象的1-1.5倍。
老年代的內存大小設置為老年代存活對象的2-3倍。
注意在新的JVM內存模型下已經沒有PermSize而是變化為Metaspace，因此需要考慮Heap內存和Metaspace大小的配比，同時還需要考慮相關的垃圾回收機制是采用哪種類型等。
對于JVM內存溢出問題，我前面寫過一篇專門的分析文章可以參考。
從表象到根源-一個軟件系統(tǒng)JVM內存溢出問題分析解決全過程
軟件程序性能問題分析
在這里首先要強調的一點就是，當我們發(fā)現性能問題后首先想到的就是擴展資源，但是大部分的性能問題本身并不是資源能力不夠導致，而是我們程序實現上出現明顯缺陷。
比如我們經常看到的大量循環(huán)創(chuàng)建連接，資源使用了不釋放，SQL語句低效執(zhí)行等。
為了解決這些性能問題，最好的方法仍然是在事前控制。其中包括了事前的代碼靜態(tài)檢查工具的使用，也包括了開發(fā)團隊對代碼進行的Code Review來發(fā)現性能問題。
所有已知的問題都必須形成開發(fā)團隊的開發(fā)規(guī)范要求，避免重復再犯。
業(yè)務系統(tǒng)性能問題擴展思考
對于業(yè)務系統(tǒng)的性能優(yōu)化，除了上面談到的標準分析流程和分析要素外，再談下其它一些性能問題引發(fā)的關鍵思考。
上線前的性能測試是否有用？
有時候大家可能覺得奇怪，為何我們系統(tǒng)上線前都做了性能測試，為何上線后還是會出現系統(tǒng)性能問題。那么我們可以考慮下實際上我們上線前性能測試可能存在的一些無法真實模擬生產環(huán)境的地方，具體為：
硬件能否完全模擬真實環(huán)境？最好的性能測試往往是直接在搭建完成的生產環(huán)境進行。
數據量能否模擬實際場景？真實場景往往是多個業(yè)務表都已經存在大數據量的積累而非空表。
并發(fā)能否模擬真實場景？一個是需要錄制復合業(yè)務場景，一個是需要多臺壓測機。
而實際上我們在做性能測試的時候以上幾個點都很難真正做到，因此要想完全模擬出生產真實環(huán)境是相當困難的，這也導致了很多性能問題是在真正上線后才發(fā)現。
系統(tǒng)本身水平彈性擴展是否完全解決性能問題？
第二個點也是我們經常談的比較多的點，就是我們的業(yè)務系統(tǒng)在進行架構設計的時候，特別是面對非功能性需求，我們都會談到系統(tǒng)本身的數據庫，中間件都采用了集群技術，能夠做到彈性水平擴展。那么這種彈性水平擴展能力是否又真正解決了性能問題？
實際上我們看到對于數據庫往往很難真正做到無限的彈性水平擴展，即使對于Oracle RAC集群往往也是最多擴展到單點的2到3倍性能。對于應用集群往往可以做到彈性水平擴展，當前技術也比較成熟。
當中間件能夠做到完全彈性擴展的時候，實際上仍然可能存在性能問題，即隨著我們系統(tǒng)的運行和業(yè)務數據量的不斷積累增值。實際上你可以看到往往非并發(fā)狀態(tài)下的單用戶訪問本身就很慢，而不是說并發(fā)上來后慢。因此也是我們常說的要給點，即：
單點訪問性能正常的時候可以擴展集群來應對大并發(fā)狀態(tài)下的同時訪問 單點訪問本身性能就有問題的時候，要優(yōu)先優(yōu)化單節(jié)點訪問性能
業(yè)務系統(tǒng)性能診斷的分類
對于業(yè)務系統(tǒng)性能診斷，如果從靜態(tài)角度我們可以考慮從以下三個方面進行分類
操作系統(tǒng)和存儲層面 中間件層面（包括了數據庫，應用服務器中間件） 軟件層面（包括了數據庫SQL和存儲過程，邏輯層，前端展現層等）
那么一個業(yè)務系統(tǒng)應用功能出現問題了，我們當然也可以從動態(tài)層面來看實際一個應用請求從調用開始究竟經過了哪些代碼和硬件基礎設施，通過分段方法來定位和查詢問題。
比如我們常見的就是一個查詢功能如果出現問題了，首先就是找到這個查詢功能對應的SQL語句在后臺查詢是否很慢，如果這個SQL本身就慢，那么就要優(yōu)化優(yōu)化SQL語句。如果SQL本身快但是查詢慢，那就要看下是否是前端性能問題或者集群問題等。
軟件代碼的問題往往是最不能忽視的一個性能問題點
對于業(yè)務系統(tǒng)性能問題，我們經常想到的就是要擴展數據庫的硬件性能，比如擴展CPU和內存，擴展集群，但是實際上可以看到很多應用的性能問題并不是硬件性能導致的，而是由于軟件代碼性能引起的。對于軟件代碼常見的性能問題我在以往的博客文章里面也談過到，比較典型的包括了。
循環(huán)中初始化大的結構對象，數據庫連接等 資源不釋放導致的內存泄露等 沒有基于場景需求來適度通過緩存等方式提升性能 長周期事務處理耗費資源 處理某一個業(yè)務場景或問題的時候，沒有選擇最優(yōu)的數據結構或算法
以上都是常見的一些軟件代碼性能問題點，而這些往往需要通過我們進行Code Review或代碼評審的方式才能夠發(fā)現出來。因此如果要做全面的性能優(yōu)化，對于軟件代碼的性能問題排查是必須的。
通過IT資源監(jiān)控或APM應用工具來發(fā)現性能問題
對于性能問題的發(fā)現一般有兩條路徑，一個就是通過我們IT資源的監(jiān)控，APM的性能監(jiān)控和預警來提前發(fā)現性能問題，一個是通過業(yè)務用戶在使用過程中的反饋來發(fā)現性能問題。
APM應用性能管理主要指對企業(yè)的關鍵業(yè)務應用進行監(jiān)測、優(yōu)化，提高企業(yè)應用的可靠性和質量，保證用戶得到良好的服務，降低IT總擁有成本(TCO)。
資源池-》應用層-》業(yè)務層
這個可以理解為APM的一個關鍵點，原有的網管類監(jiān)控軟件更多的是資源和操作系統(tǒng)層面，包括計算和存儲資源的使用和利用率情況，網絡本身的性能情況等。但是當要分析所有的資源層問題如何對應到具體的應用，對應到具體的業(yè)務功能的時候很難。
傳統(tǒng)模式下，當出現CPU或內存滿負荷的時候，如果要查找到具體是哪個應用，哪個進程或者具體哪個業(yè)務功能，哪個sql語句導致的往往并不是容易的事情。在實際的性能問題優(yōu)化中往往也需要做大量的日志分析和問題定位，最終才可能找到問題點。
比如在我們最近的項目實施中，結合APM和服務鏈監(jiān)控，我們可以快速的發(fā)現究竟是哪個服務調用出現了性能問題，或者快速的定位出哪個SQL語句有驗證的性能問題。這個都可以幫助我們快速的進行性能問題分析和診斷。
資源上承載的是應用，應用本身又包括了數據庫和應用中間件容器，同時也包括了前端；在應用之上則是對應到具體的業(yè)務功能。因此APM一個核心就是要將資源-》應用-》功能之間進行整合分析和銜接。
而隨著DevOps和自動化運維的思路推進，我們更加希望是通過APM等工具主動監(jiān)控來發(fā)現性能問題，對于APM工具最大的好處就是可以進行服務全鏈路的性能分析，方便我們發(fā)現性能問題究竟發(fā)生在哪里。比如我們提交一個表單很慢，通過APM分析我們很容易發(fā)現究竟是調用哪個業(yè)務服務慢，或者是處理哪個SQL語句慢。這樣可以極大的提升我們性能問題分析診斷的效率。
來源：www.cnblogs.com/you-men/p/14058806.html
如喜歡本文，請點擊右上角，把文章分享到朋友圈
推薦閱讀：
END
長按二維碼/微信掃碼? 添加作者
閱讀原文