? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?郭柏雅

本文案例是我們品課學院在銀行系統性能測試第一個案例，由發生至解決，通過對業務邏輯的認知、測試環境的了解、測試腳本的開發、服務的監控分析優化、操作系統的監控分析與優化、從基礎軟件到架構級優化改良、測試報告的編寫等，一路艱辛，但是最終柳暗花明。

?問題總結回顧

1.??? 每一次攻堅性能故障問題都是一次精喜的探險，需要清醒頭腦、大局觀的分析意識、紮實的專業基礎等更要凝結你的意誌和自信心，因為這是一個艱苦而有趣的過程。

2.??? 紙上得來終覺淺， 絕知此事要躬行，一切性能測試與問題的分析優化，不是看完一篇文章做完幾個項目就能提升，需要持續興趣吃苦的煎熬來不斷提煉優化自己的知識與技能才能慢慢的在博大精深的性能世界裏認知了解遊趟。

故事案例發生原因

故事原因：某知名城商行代支付管理系統，因上線一段時間後客戶量劇增，在生產運行過程中偶爾會出現資源爭用現象，客戶領導擔心目前環境無法滿足業務量日益增長發展趨勢。 因此該行邀請一家合作公司幫忙測試分析問題，該供應商跟他們合作關系一直友好也很支持，派了一位十幾年性能測試經驗的行業專家過去，因業務邏輯、技術框、測試腳本等編寫比較復雜，工作量也大支持了十幾天後，因該性能測試專家臨時有事情，只能忍痛隱退，這時該供應商剛好項目緊張人員無法抽取，找到我們品課學院，讓我們幫忙測試，得此機會我和檸檬老師兩個利用周五晚上和周末時間過去支持，檸檬老師主要負責壓力測試和測試數據維護工作，我負責性能定位分析優化和測試報告編寫，因時間緊迫，測試過程中沒有使用第三方工具，都是直接使用命令或者數據庫自帶的函數等進行監控分析。

?測試實施場景

?到客戶現場後，客戶開發人員很耐心的幫我講解了業務邏輯、技術框架等以及環境情況，也介紹了目前情況，在高並發下TPS 大概在300筆/S，而且上下波動很大，目前尚未查出具體問題原因，希望能在最短時間內幫忙定位出來，不然已經臨近上線，還好長期在金融行業做性能測試，能短時間內理清問題的來龍去脈，也最快的時間內切入到團隊中。因每個人寫腳本、參數化方式風格不一樣，我也看了之前腳本編寫很規範，但是每個人對腳本的使用方式有點差異性，我花了點時間重新修改編寫LR腳本、shell腳本，估計是運氣好或者有相關項目經驗，在壓力測試過程中，就發現問題並提供解決方案，通過描述問題原理以及操作系統工作原理、交易腳本使用原理等跟客戶開發人員交流後，就這樣客戶也在最短時間內從陌生到認可，並得到大力支持，運氣來了，做事就是給力。

這次接口實時交易測試數據準備相對比較簡單，不用準備存量的業務數據，只需把對應的業務腳本T0交易的腳本參數化好，確保高並發下不出現業務數據重復即可，而針對T0插入到過程表的數據，通過使用verify交易進行時時查詢處理到目標表，具體腳本如下：

1、? 實時交易都是接口報文，分為socket協議腳本T0交易和http協議腳本verify交易，其中HTTP協議腳本是對T0的socket腳本插入到過程表數據進行查詢後更新然後插入到目標表。

2、? 批量腳本，需要每秒鐘傳輸一個文本文件1.5M的txt文件到應用服務器指定目錄下，讓後臺去處理。

?

Socket協議腳本相對比較簡單，類似如下：

? ? ? ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

測試過程問題分析

優化前：TPS只有304筆/秒，而且不穩定，在並發到一定時間後，TPS就掉下去，而且交易成功率80%不到，隨時間推移交易成功率也會持續降低，沒辦法滿足預期指標要求550筆/S，交易成功率99%，優化前測試結果如下圖：

? ? ? ?

1、數據庫問題分析優化方法

在壓力測試過程中發現TPS不高，而且隨著用戶並發數增加TPS反而降低，交易成功率也逐漸下降，看了各服務器資源使用都在理想狀態下，與實現懷疑下數據庫是否有問題，因測試交易是接口測試，語法相對簡單，都是單表操作，查看了數據庫相應的parameter數值，發現都是默認配置，無法滿足高並發，於是建議他們DBA修改下SGA、連接數等數據庫參數，，重新並發發現TPS有明顯提升，但是還是沒辦法滿足指標要求，因為磁盤IO高了，於是抓取語法分析，都是類似如下鎖：Select ….for update,說明問題是Lock For Update,Lock Row Share?，在並發時打開一個遊標，以及返回集中的數據行都將處於行級(Row-X)獨占式鎖定，其他對象只能查詢這些數據行，不能進行update、delete或select for update操作。

3級鎖有：Insert, Update, Delete, Lock Row Exclusive
說明在沒有commit之前插入同樣的一條記錄會沒有反應, 因為等待上一個鎖釋放掉才能繼續工作。語法是沒辦法修改，所以把單筆commit，改為多筆同時commit，解決高並發問題。

?

1.1? 表面性能問題監控

監控數據庫磁盤IO寫入一直偏高，如下圖：

oracle函數看到後臺數據庫塊寫數據問題情況，如下，

1.2 內核問題定位分析

通過與開發人員分析，因為T0交易在高並發寫入到過程表，這時HTTP接×××易會去查詢出對應的過程表數據，然後for update，最後在更新插入到目標表。當過程表數據量很大情況下，會出現鎖現象，如下圖，看到過程表數據時時動態增加變化：

而在過程表數據量逐漸增加情況下，前端TPS 也在降低，失敗率也在增加，如下圖：

?

? ? ? 2、應用方面問題分析優化

而應用方面，在通過java批處理方式調度實時處理過程表數據後，對於一些業務規則判斷代碼也做了優化，後面我們在java應用中監控到java內存回收使用有點異常，發現JVM參數配置不合理，內存回收不及時問題，通過優化配置JVM後，以及把對應應用日誌記錄級別做了修改後，TPS可以穩定在800筆/S，以上。

3、其他問題分析優化方法? ??

經分析後，在To對應的SOCKET交易與過程表verify對應的HTTP交易腳本並發數配比改為2：1，然後開發人員後臺調度時時java批處理及時處理掉T0交易的數據，確保過程表數據量都在100筆以下，

這時的TPS，穩定在660筆/S，交易成功率也在99.9%，不會大批量出錯現象。

??

性能優化攻堅戰後期：

測試環境硬件配置：應用服務器三臺，數據庫一臺，負載均衡服務器一臺，在高並發下，三臺服務器處理很輕松，但是在更高用戶並發下，TPS還是上不去，資源利用率也不行，反而失敗率會增加，客戶領導希望能繼續挖掘問題，因此只能在繼續發揮想象力，從全局角度看待問題，碰巧發現操作系統的文件句柄數量不足，於是讓客戶幫忙修改了下，發現TPS有適當提升，可以達到800筆/S，但是還是不能滿足現狀，發現壓力測試時間久了，TPS就會抖動，而且越往後越厲害，說明資源釋放有點問題，需要時間釋放，然後才能回收，TPS才能提升，發現HTTP交易verify在處理過程表數據的時候，端口申請數量一直增加不能馬上釋放，以為是操作系統參數設置問題，於是就修改了操作系統參數，tcp_syncookies 等參數，但是在高並發下還是有問題，後來經推敲分析是verify腳本處理過程表數據給下遊時是走HTTP協議，高並發下需要申請不同端口等，只能架構調整分離，然後在負載分發方式處理，TPS終於從800筆/S，直接飆到大於5000筆/S，而且成功率達到99.99%，資源利用率也上去了，終於大功告成。

我們的攻堅團隊

在測試過程中，客戶領導、兩位開發人員、我和檸檬一起加班熬夜分析攻堅各種技術問題，才能短時間內順利的把任務完成。

性能問題定位分析是一種技術活，性能優化分析是一種藝術活，達芬奇的藝術來源以長期技術的鍛煉積累得來靈感，而性能測試分析優化也是如此。對於一個大項目的性能測試分析優化，不是一個人能完成的事情，是需要一個團隊協作，是需要一個擁有高度的執行力的團隊，是一個責任分明的團隊，在應對突發、嚴重、緊急情況時，能通過專門的攻堅團隊來解決這類問題，這個團隊應該包括項目組的核心專業人員，有較強的動手能力和研究能力，能夠變通解決問題，思路開闊。他們的作用是至關重要的，往往可能決定項目的成敗。

TPS從300筆/秒到5500筆/秒的性能測試優化之路