外賣聚合服務性能測試總結

代碼質量過關，性能測試就只是走個過場。

上週對目前開發的外賣聚合服務進行了一週的負載及壓力測試，收穫了一些經驗，也積攢了一些教訓，和團隊中的小夥伴們一塊兒對一款互聯網產品上線前的壓力測試有了系統的瞭解與實踐，在這裏分享一下心得，也藉此感謝小夥伴們跟我一塊兒破了連續加班9天的最長記錄，若是「有幸」被領導看到，記得給咱們加個雞腿兒，哈哈。
既然要求加雞腿兒，那就得先用成果來講話。

指標	壓測改善前	壓測改善後	結論
TPS	50/s~70/s	350/s~380/s	可支持一秒內300人同時下單
平均響應時間	5s	0.2s	遠遠低於餓了麼要求的3s響應時間

這個結果，着實讓小夥伴們頗爲興奮了一陣子，不過每天看《甄嬛傳》宮心斗的我，必須適時地潑一下冷水：壓測改善後性能提高的有多高，就說明大家當初寫的代碼有多爛。。。

話雖這麼說，一個團隊中人員經驗有高低，習慣有好壞，代碼質量不免良莠不齊，因此作好壓力測試，一來能夠提升產品質量，二來能夠幫助你們發現開發中的問題，仍是很是重要的。因此隨着測試技術的發展，許多公司也單獨把性能測試獨立出來，創建專門的性能測試小組或團隊，在實施的過程當中創建獨立的流程與規範。反思咱們一個月前的那次壓力測試，在性能需求模糊的狀況下，隨便找了一個性能測試工具就開始進行性能測試了，在這種狀況下獲得的性能測試結果天然很難體現系統真實的能力，與系統真實的性能也相距甚遠。
此次咱們的測試規範了流程，具體以下：

性能需求分析

性能需求分析是整個性能測試工做開展的基礎。在這個階段要肯定測試的目標和範圍。測試目標應該藉助於有行業經驗的開發人員、領導的經驗，按照客戶的要求來定；測試範圍則主要分析系統的功能模塊進行調研與分析。
做爲外賣聚合服務，本項目的：

• 測試目標：可以支撐訂餐高峯期的併發量。根據百度對「大客戶」的定義（單店日訂單量大於1000），根- 據外賣數據分析，訂單高峯爲中午和晚上的2個小時，即平均每分鐘爲1000/2/60=8單，若按100家店來計算，平均每秒鐘爲8*100/60≈14單。

• 測試範圍：高頻且對併發有要求的接口有兩類：輸入：美團和餓了麼的推單接口；輸入：由聚合服務向ERP推單的接口。

性能測試計劃

肯定性能測試的需求以後，就要制定性能測試計劃。測試計劃的大概內容包括：

• 項目的簡單背景描述：支撐客戶外賣業務，保持訂單高峯期服務的穩定性，提高服務性能的極限；

• 本次性能測試的需求與目的：參照性能需求分析；

• 測試環境的準備：使用阿里雲ECS(1核8G，SLB帶寬無限制，使用集團網絡，預測會有限流)；

• 測試數據的準備：編寫測試腳本

• 人員配置：開發人員、運維人員、需求人員

• 測試時間：一週

• 測試環境搭建

• 測試環境搭建分硬件環境和軟件環境，因爲咱們用的是阿里雲服務，因此硬件環境無需搭建，軟件環境建議畫出大體的系統架構圖，做爲性能測試人員，須要對系統中的每一個部分有深刻的瞭解，由於性能測試的分析並非死盯着系統應用那一層，中間件、數據庫、系統、硬件都有可能成爲系統的瓶頸。O2O的大體架構圖以下（剛買了wecom的數位板，請原諒我粗鄙的畫風）：
  

性能工具的引入

工具的引入分爲自行開發與引入市面上的現有工具。市面上的現有工具又分爲收費與開源免費，各有各的優缺點。咱們要作的是對需求進行分析，從成本，購買成本，開發成本，現有開源工具的二次開發成本，人員學習使用成本以及時間成本等。

在這裏再強調一點，不是隻有壓力測試工具屬於性能工具，在性能測試過程當中所用到的工具都屬於性能工具，如測試數據生成工具，性能監控工具等。

工具的選擇上，咱們使用了LoadRunner、jProfiler和nmon這三款工具。LoadRunner用來進行負載和壓力測試，jProfiler用來進行性能分析，nmon用來監控系統負載。

測試的執行

測試的執行要根據選擇的工具、測試的功能和開發的腳原本進行。咱們使用LoadRunner建立虛擬用戶，從1到1000都，運行時間從10分鐘到1天，都進行了測試。

軟件硬件配置調整與優化

如同文章開頭說的，若是代碼寫的好，性能測試不過是走走過場，這時就應該出測試報告了。反觀咱們的代碼，須要優化的地方就不少了。首先上兩張測試初期的截圖：

從圖中能夠發現，tps僅爲19/s，且存在大量報錯，響應時間也在0.5s左右，甚至會超過3s；cpu和內存的佔用接近100%。出現這種狀況的緣由有兩方面，一是目前服務器的配置確實偏弱，1核8G，須要同時跑網關、外賣等多服務，且此時並未分多節點，系統壓力較大；而是代碼中存在大量待優化的地方，總結以下：

• 代碼中存在大量數據庫鏈接使用未關閉的狀況，致使後續事務沒法獲取數據庫鏈接；

• logstach配置錯誤，致使Redis數據沒法及時導出，2G的存儲量很快就會被佔滿報錯；

• MQ隊列使用錯誤，爲每次事務單獨創建了隊列，且這些隊列沒法自動清除；

• 日誌級別爲info，致使CPU很大一部分的是用來處理日誌相關的功能；

• 數據庫配置錯誤，致使性能緩慢

• 網關配置有誤，致使限流的發生
  -對接的ERP方代碼有誤

此處，系統的架構圖做用就很明顯了，在日誌報錯信息不明確的狀況下，能夠查看每部分的監控信息，查出報錯緣由；若是沒有架構圖，則只能東一榔錘西一棒頭，效率很低。

通過對上述問題的修復，且將ECS升級爲2核16G，三節點以後，tps達到了380/s，提高了接近20倍（對外能夠吹牛皮，對內實在是汗顏），響應時間也控制在了0.1s左右。

系統的調優是個循環的過程，在咱們的實際操做中，每每是改善完一點就再測試一次，再次尋找下一個致使問題的點。雖然測試調優的過程很枯燥，但每一次數字的提高老是能讓咱們興奮。

總結

這是一次成功的性能測試，但在測試調優中佔用了很多的人力和時間，去改善由於代碼的不足出現的問題，對項目的成本和進度來講，是一次失敗。代碼質量的問題在項目之初就應該考慮到，當初若是作好代碼審查工做，那麼性能測試的時間可以縮短一半。這也是此次性能測試最大的教訓。

在這裏衷心的但願咱們的代碼質量愈來愈好，讓之後的壓力測試僅僅是走個過場而已。