某項目在上線前的APT（Application Performance Testing應用程序性能測試）過程中發現性能問題，性能測試結果影響是否上線，緊急求助外部項目組技術專家。

因分屬不同項目，只能通過項目組提供的信息進行分析。

第一輪評審

現象

根據APT性能監控截圖，左圖為并發用戶數和CPU使用率，右圖為單獨的CPU使用率情況。APT測試情景為并發用戶數以5分鐘為周期進行增加，增加用戶數25人，在40分鐘后達到最終200并發用戶并保持1小時200用戶活動狀態。

很明顯看出用戶穩定后CPU使用率還在持續增長，懷疑有內存泄露問題。

?

?

分析

第一輪我們拿到的是API源代碼，日志里面出現outOfMemory錯誤，檢查一遍發現API控制器方法中創建了HttpClient實例。詢問開發組回復是因為每次請求URL不同，根據經驗推薦采用HttpWebRequest替換調HttpClient。同時我們調查是否是由HttpClient引起的內存泄漏問題。

由Google搜索結果HttpClient確實有內存泄漏的報告，我們著手寫了一個小程序比較HttpClient和HttpWebRequest性能，并通過JMeter在本地進行性能測試。

HttpClient和HttpWebRequest性能比較

測試環境

測試URL:?https://www.baidu.com/#{number}?(number變量為隨機或遞增以防止HTTP緩存干擾性能對比結果)

測試節奏：10秒周期，并發用戶從1到200增長

測試結果（內存使用量）

• HttpClient: 455MB

• HttpWebRequest: 242MB

圖1: HttpClient (GetAsync)

?

圖2: HttpWebRequest (請忽略結尾處由網絡連接問題出現的凸起)

?

結論

將HttpClient更換使用HttpWebRequest，但根據HttpClient內存使用陡增幅度估計還有其它問題，通知開發組繼續調查并提供相關資料。

第二輪評審

現象

比較IIS內存使用和SQL Server的內存使用發現相同的增長趨勢，猜測瓶頸出現在數據庫查詢中（如果是拒絕訪問數據庫不會出現內存增長，一定是已經連接了數據庫并產生查詢問題導致）。

推薦增加查詢操作日志獲得查詢執行時間，安裝數據庫性能監視工具（可使用Windows Server自帶的Performance Monitor或者第三方工具如AppDynamic），查看查詢的執行計劃（Execution Plan）。

圖3: SQL Server – 內存 - % committed Bytes (內存使用)

?

圖4: MS IIS – 內存 - % Committed Bytes (內存使用)

?

同時經過了解API還會調用上游系統的API（API嵌套），所以考慮檢查日志是否存在因上游API瓶頸導致調用失敗，導致異常阻塞請求進程。也會出現相同的現象，開發組著手調查。

上游API問題通過調整系統配置消除瓶頸，但SQL Server性能問題還無任何頭緒。只能安排時間一起評審數據庫及相應查詢性能問題。

第三輪評審

背景：

測試總時長1小時40分：從最開始每隔1分鐘增長5個并發用戶，40分鐘左右并發數加到200，然后維持并發用戶不變，又執行1小時

現象：

達到200并發后的20分左右時， CPU的使用率達到30% 左右之后保持相對平穩的比例，但是在這之后的執行過程中 request queued 曲線出現排隊現象， Thread Count 曲線出現突然增長的情況，并且同是response time 翻倍增長。

上次報告沒有HTTP 5xx錯誤，本次出現HTTP 5xx錯誤，27日錯誤數量激增。

程序中有從上百萬條數據中抽取數據生成級聯選擇（下拉菜單）的UI元素。

程序中使用了Http Cache，但在準備Cache數據的邏輯中沒有鎖處理，數據準備時間過長，就會造成期間大量請求訪問數據庫。

性能測試報告中SQL Server也顯示出周期性達到100% CPU利用率，引發數據庫連接超時，同時應用程序出現GATEWAY_TIMEOUT。

System.Data.Entity.Core.EntityException: The underlying provider failed on Open. ---> System.InvalidOperationException: Timeout expired.? The timeout period elapsed prior to obtaining a connection from the pool.? This may have occurred because all pooled connections were in use and max pool size was reached.

?

?

?

分析

因已經做過兩輪評審，開發組這次提供了全面的資料，通過代碼評審發現邏輯中有使用LDAP（Windows活動目錄輕量目錄訪問協議Light Directory Access Protocol）遍歷登陸者所有活動目錄下的組。

此邏輯可能會產生請求ADFS查詢的瓶頸，阻塞請求。

同時發現部分被查詢的表中沒有創建索引（這個是在最初問過開發團隊但得到的回答是肯定的）并進行索引優化，另外，API采用.NET Entity Framework編寫，由SQL查詢監控看出因無索引導致EF生成相同表的嵌套（笛卡爾積）查詢，是導致表遍歷和產生表鎖的主要原因。

對于大量出現的5xx錯誤，因上次性能測試沒有，主要針對修改的代碼進行評審發現增加了EF查詢邏輯，這也是導致循環嵌套的原因。

結論

表索引優化是主要解決辦法。EF查詢最終改為明文查詢并SQL查詢優化。

總結

性能問題首先由測試入手，根據測試報告發現錯誤和性能瓶頸，主要以解決錯誤消除瓶頸為主要原則。對于有數據庫存在的情景，注意查詢和索引優化，保證連接池有效支持應用并發。問題調研期間要了解整體架構（本次API嵌套問題和LDAP的使用都是后期由開發組告知）和所使用的技術，才能給出全面建議。從開發組角度應該訓練發現性能問題的敏感度。所有問題的發現和解決以測試事實數據說話，不會存在莫須有的性能問題，所有問題皆有因緣。

原文地址：https://www.cnblogs.com/richardcuick/p/11008387.html

總結

以上是生活随笔為你收集整理的应用性能问题解决实际案例的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。