1. 現象

最近做的效能測試中，有一支交易隨著壓測時間的增加，響應時間越來越慢，TPS越來越低 。壓測十二個小時之後的效果平均響應時間和TPS如下圖: 整個場景是要錄入一個貸款的客戶資訊，使用50使用者併發壓測12小時以上；其中輸入完客戶資訊後，點選儲存按鈕這個操作，隨著壓測的進行，響應時間越來越慢。並且停止壓測後，過一段時間，即使使用一個使用者進行同樣的操作，響應時間還是在壓測之後的基礎上，並不會恢復到最初壓測的時間。整個場景中只有這一個操作會越來越慢，其他操作響應時間很穩定。

2. 定位問題

首先排除了物理資源和中介軟體引起的問題，如果是這些問題，整支交易的所有操作應該都會越來越慢，而不會只體現在這一個方法上。而且通過監控資源，伺服器CPU、記憶體、IO都不存在瓶頸。初步判斷是該方法本身出現了問題，肯定出現了資源佔用後不能釋放的問題，導致隨著壓測的進行，響應時間越來越慢，並且停止壓測一段時間後，資源也不會釋放。 開發同事通過對該方法的除錯，並沒有發現明顯的問題，於是只能使用排除法，分步註釋該方法的程式碼塊，最後把整個方法體完全註釋之後，只返回null結果，壓測一段時間後，問題仍然存在。又判斷問題不是出現在方法本身，有可能是在方法的上一層，或者是傳入的引數物件有問題。開發使用的是Spring架構，由於對Spring不是太瞭解，這裡只能描述大概的問題：Spring有自己的物件持久化方法，需要把前端頁面傳過來的表單資料解析成物件，然後在把相應的資料儲存到資料庫中（這塊可能描述的不正確），但是這個物件特別大，裡面還有很多list，導致越來越多的物件需要被持久化，佔用的資源又不會釋放，導致了響應時間越來越慢。

3. 調優

不適用Spring 自帶的持久化技術，開發自己寫程式碼實現了這一邏輯，好像是把jackjson改成了gson進行JSON和Java物件轉換。改完之後再壓測，問題完美的解決了，所有操作平均響應時間都是趨於平穩的。

4. TODO

後續要把Spring學習下，否則不知道開發說的什麼。