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

上周對目前開發(fā)的外賣聚合服務進行了一周的負載及壓力測試，收獲了一些經(jīng)驗，也積攢了一些教訓，和團隊中的小伙伴們一起對一款互聯(lián)網(wǎng)產(chǎn)品上線前的壓力測試有了系統(tǒng)的了解與實踐，在這里分享一下心得，也借此感謝小伙伴們跟我一起破了連續(xù)加班9天的最長記錄，如果“有幸”被領導看到，記得給我們加個雞腿兒，哈哈。
既然要求加雞腿兒，那就得先用成果來說話。

指標壓測改善前壓測改善后結論
TPS50/s~70/s350/s~380/s可支持一秒內300人同時下單
平均響應時間5s0.2s遠遠低于餓了么要求的3s響應時間

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

話雖這么說，一個團隊中人員經(jīng)驗有高低，習慣有好壞，代碼質量難免參差不齊，所以做好壓力測試，一來可以提高產(chǎn)品質量，二來可以幫助大家發(fā)現(xiàn)開發(fā)中的問題，還是非常重要的。所以隨著測試技術的發(fā)展，許多公司也單獨把性能測試獨立出來，建立專門的性能測試小組或團隊，在實施的過程中建立獨立的流程與規(guī)范。反思我們一個月前的那次壓力測試，在性能需求模糊的情況下，隨便找了一個性能測試工具就開始進行性能測試了，在這種情況下得到的性能測試結果自然很難體現(xiàn)系統(tǒng)真實的能力，與系統(tǒng)真實的性能也相距甚遠。
這次我們的測試規(guī)范了流程，具體如下：
Android培訓,安卓培訓,手機開發(fā)培訓,移動開發(fā)培訓,云培訓培訓

性能需求分析

性能需求分析是整個性能測試工作開展的基礎。在這個階段要確定測試的目標和范圍。測試目標應該借助于有行業(yè)經(jīng)驗的開發(fā)人員、領導的經(jīng)驗，按照客戶的要求來定；測試范圍則主要分析系統(tǒng)的功能模塊進行調研與分析。
作為外賣聚合服務，本項目的：

  • 測試目標：能夠支撐訂餐高峰期的并發(fā)量。根據(jù)百度對“大客戶”的定義（單店日訂單量大于1000），根- 據(jù)外賣數(shù)據(jù)分析，訂單高峰為中午和晚上的2個小時，即平均每分鐘為1000/2/60=8單，若按100家店來計算，平均每秒鐘為8*100/60≈14單。

  • 測試范圍：高頻且對并發(fā)有要求的接口有兩類：輸入：美團和餓了么的推單接口；輸入：由聚合服務向ERP推單的接口。

性能測試計劃

確定性能測試的需求之后，就要制定性能測試計劃。測試計劃的大概內容包括：

  • 項目的簡單背景描述：支撐客戶外賣業(yè)務，保持訂單高峰期服務的穩(wěn)定性，提升服務性能的極限；

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

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

  • 測試數(shù)據(jù)的準備：編寫測試腳本

  • 人員配置：開發(fā)人員、運維人員、需求人員

  • 測試時間：一周

  • 測試環(huán)境搭建

  • 測試環(huán)境搭建分硬件環(huán)境和軟件環(huán)境，由于我們用的是阿里云服務，所以硬件環(huán)境無需搭建，軟件環(huán)境建議畫出大致的系統(tǒng)架構圖，作為性能測試人員，需要對系統(tǒng)中的每個部分有深入的了解，因為性能測試的分析并不是死盯著系統(tǒng)應用那一層，中間件、數(shù)據(jù)庫、系統(tǒng)、硬件都有可能成為系統(tǒng)的瓶頸。O2O的大致架構圖如下（剛買了wecom的數(shù)位板，請原諒我粗鄙的畫風）：
    Android培訓,安卓培訓,手機開發(fā)培訓,移動開發(fā)培訓,云培訓培訓

    性能工具的引入

    工具的引入分為自行開發(fā)與引入市面上的現(xiàn)有工具。市面上的現(xiàn)有工具又分為收費與開源免費，各有各的優(yōu)缺點。我們要做的是對需求進行分析，從成本，購買成本，開發(fā)成本，現(xiàn)有開源工具的二次開發(fā)成本，人員學習使用成本以及時間成本等。

在這里再強調一點，不是只有壓力測試工具屬于性能工具，在性能測試過程中所用到的工具都屬于性能工具，如測試數(shù)據(jù)生成工具，性能監(jiān)控工具等。

工具的選擇上，我們使用了LoadRunner、jProfiler和nmon這三款工具。LoadRunner用來進行負載和壓力測試，jProfiler用來進行性能分析，nmon用來監(jiān)控系統(tǒng)負載。

測試的執(zhí)行

測試的執(zhí)行要根據(jù)選擇的工具、測試的功能和開發(fā)的腳本來進行。我們使用LoadRunner創(chuàng)建虛擬用戶，從1到1000都，運行時間從10分鐘到1天，都進行了測試。

軟件硬件配置調整與優(yōu)化

如同文章開頭說的，如果代碼寫的好，性能測試不過是走走過場，這時就應該出測試報告了。反觀我們的代碼，需要優(yōu)化的地方就很多了。首先上兩張測試初期的截圖：

Android培訓,安卓培訓,手機開發(fā)培訓,移動開發(fā)培訓,云培訓培訓

從圖中可以發(fā)現(xiàn)，tps僅為19/s，且存在大量報錯，響應時間也在0.5s左右，甚至會超過3s；cpu和內存的占用接近100%。出現(xiàn)這種情況的原因有兩方面，一是目前服務器的配置確實偏弱，1核8G，需要同時跑網(wǎng)關、外賣等多服務，且此時并未分多節(jié)點，系統(tǒng)壓力較大；而是代碼中存在大量待優(yōu)化的地方，總結如下：

  • 代碼中存在大量數(shù)據(jù)庫連接使用未關閉的情況，導致后續(xù)事務無法獲取數(shù)據(jù)庫連接；

  • logstach配置錯誤，導致Redis數(shù)據(jù)無法及時導出，2G的存儲量很快就會被占滿報錯；

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

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

  • 數(shù)據(jù)庫配置錯誤，導致性能緩慢

  • 網(wǎng)關配置有誤，導致限流的發(fā)生
    -對接的ERP方代碼有誤

此處，系統(tǒng)的架構圖作用就很明顯了，在日志報錯信息不明確的情況下，可以查看每部分的監(jiān)控信息，查出報錯原因；如果沒有架構圖，則只能東一榔錘西一棒頭，效率很低。

經(jīng)過對上述問題的修復，且將ECS升級為2核16G，三節(jié)點之后，tps達到了380/s，提升了接近20倍（對外可以吹牛皮，對內實在是汗顏），響應時間也控制在了0.1s左右。

系統(tǒng)的調優(yōu)是個循環(huán)的過程，在我們的實際操作中，往往是改善完一點就再測試一次，再次尋找下一個導致問題的點。雖然測試調優(yōu)的過程很枯燥，但每一次數(shù)字的提升總是能讓我們興奮。

總結

這是一次成功的性能測試，但在測試調優(yōu)中占用了不少的人力和時間，去改善因為代碼的不足出現(xiàn)的問題，對項目的成本和進度來說，是一次失敗。代碼質量的問題在項目之初就應該考慮到，當初如果做好代碼審查工作，那么性能測試的時間能夠縮短一半。這也是這次性能測試最大的教訓。

在這里衷心的希望我們的代碼質量越來越好，讓以后的壓力測試僅僅是走個過場而已。

http://www.cnblogs.com/depsi/p/7234701.html