1. 首頁 > 科技 > >

創投圈|如何做“健康碼”的性能壓測

創投圈

創投圈|如何做“健康碼”的性能壓測

文章圖片


為什么要做壓測 【創投圈|如何做“健康碼”的性能壓測】隨著無線設備的普及和 5G 的大力建設 ， 越來越多的線上系統、小程序成為了人們生活中必不可少的工具 。 對于這些工具 ， 都會面對一個問題：系統能承受多少用戶同時訪問 ， 面對突發的流量洪峰 ， 能否保證系統無故障穩定運行？
為了回答這個問題 ， 就需要在系統上線前做多輪壓力測試 ， 提前模擬出復雜的 高仿真的線上流量來驗證整體系統的高可用性 這也是實施系統高可用方案的關鍵環節 。 另外通過不同階段的壓測 ， 也完成對系統的容量規劃、瓶頸探測 ， 對系統整體能力進行驗收 ， 確保在突發的流量洪峰來臨前 ， 系統確實能夠承受即將來臨的真實線上壓力 。
從某種意義上來說 ， 壓測是系統穩定性的驗證者 。
如何實施一次準確的性能壓測
準備壓測環境
壓測的執行環境是一個老生常談的話題 ， 如果直接在生產環境執行壓測 ， 會有2個問題：









































會影響線上業務 ， 對正常訪問系統的用戶造成影響 會污染線上數據 ， 將壓測數據寫入線上數據庫 為了解決這 2 個問題 ， 一般業內采用如下幾種方案： 以上方案各有優缺點 ， 適用場景也不盡相同 ， 可以根據自己項目所處的階段靈活選擇方案 。構建壓測腳本 業內常用的壓測工具包括 JMeter、Gatling、Locust、k6、Tsung、阿里云 PTS 等 。 這些工具無一例外 ， 都需要將壓測業務的 API ， 編排為一個壓測腳本 。這一步工作的重點在確認壓測的 API ， 不要有遺漏 ， 且 API 編排的順序要符合用戶的操作邏輯 。 對于健康碼業務的壓測來說 ， 如果腳本中遺漏了登錄鑒權 API ， 那后面的刷新健康碼、查看核酸報告等 API 都會在權限校驗這步就報錯 ， 不會執行正常的業務邏輯 ， 也就無法模擬真實的業務場景 。 以上壓測工具編排腳本都有 2 個方式： 手動輸入腳本 ， 這需要腳本的編寫人員對業務非常熟悉 ， 保證不會遺漏API 。自動錄制腳本 ， 上述開源壓測工具都提供了錄制請求的代理功能 ， 開啟并配置代理后 ， 只要在頁面上模擬用戶的操作和點擊行為 ， 即可自動錄制請求 ， 并生成壓測腳本 。 同時 PTS 還提供了 Chrome 錄制插件[1
， 免代理配置 ， 可以一鍵生成 JMeter 和 PTS 壓測腳本 。 提升了腳本編寫的效率 ， 也能保證不遺漏 API 。為了避免復雜腳本中遺漏 API 的風險 ， 推薦使用錄制功能生成腳本 。確認壓力模型 這一步是在配置壓測中模擬的壓力峰值、不同 API 的壓力分布比例以及壓力值遞增模型 。 壓力值指的是模擬并發用戶數 ， 或每秒發送的請求數 。施壓模式 在設置之前 ， 需要確認施壓模式 ， 業內主要有 2 種施壓模式： 虛擬用戶(VU)模式 ， 可以理解為一個線程模擬一個真實用戶 ， 壓測時線程一直循環執行 ， 模擬用戶不停地發送請求 。吞吐量模式 ， 即每秒請求數(QPS) ， 可以直接衡量服務端的吞吐量 。在項目驗收階段 ， 很重要的一個指標就是系統的吞吐量 ， 即可支持的QPS 。 對于這種壓測場景 ， 更推薦使用吞吐量模式 ， 可以直觀的看到施壓機每秒發出的請求數 ， 并和服務端的吞吐量直接對應起來 。各 API 壓力分布比例 確認了施壓模式后 ， 需要配置不同 API 的壓力分布比例 。 比如健康碼業務 ， 100% 的用戶會調用登錄 AP 和獲取健康碼 API ， 但后面并不是所有用戶都會調用查詢核酸報告 API、查看推送信息等 API 。 所以每個 API 的準確壓力分布比例 ， 也是一次成功壓測中不可獲取的因素 。壓力值遞增模型 常見有脈沖模型 ， 階梯遞增 ， 均勻遞增 。脈沖模型會模擬流量在瞬間突然增大 ， 常用于秒殺、搶購的業務場景 。遞增模型可以模擬在一定時間段內 ， 用戶量不斷增大 ， 常用于模擬有預熱的業務場景 。除了常規的遞增模型 ， 最好在壓測中可以實現手動調速功能 ， 一是可以模擬一些非常規的流量遞增情況 ， 二是可以反復調整壓力值 ， 來復現和排查問題 。施壓流量地域分布 確定了壓力值和遞增模型后 ， 還需要確定施壓流量的地域分布 ， 應盡量擬合真實的用戶分布 ， 才能保證測試結果真實可信 。對于區域性的在線業務 ， 施壓機分布在當地的同一機房 ， 是可以理解的 。 如果是全國性的在線業務 ， 施壓機也應該按照用戶分布 ， 在全國各地域部署 。執行壓測 ， 觀察壓測指標 壓測中核心指標：請求成功率 ， 請求響應時間（RT） ， 系統吞吐量（QPS） 請求成功率不止要看全局的請求成功率 ， 還要關注一些核心API的成功率 ， 避免整體成功率達標 ， 核心 API 成功率不足的情況 。請求響應時間 ， 需要關注 99、95、90、80... 等一些關鍵分位的指標是否符合預期 ， 而平均響應時間沒有太大的參考意義 ， 因為壓測需要保證絕大部分用戶的體驗 ， 在不清楚離散程度的情況下 ， 平均值容易造成誤判 。系統吞吐量是衡量系統能承受多大訪問量的指標 ， 是壓測不可缺少的標準 。上面三個指標遇到拐點時 ， 就可以認為系統已經出現性能瓶頸 ， 可以停止壓測或調小壓力值 ， 準備分析、定位性能問題了 。除了這三個業務指標 ， 同時還應該同時觀測系統的應用監控、中間件監控和硬件監控的一些指標 ， 包括但不限于： 服務器： 網絡吞吐量 CPU 使用率 內存使用率 磁盤吞吐量 ...... 數據庫： 連接數 SQL 吞吐量 慢 SQL 數 索引命中率 鎖等待時間 鎖等待次數 ..... 中間件： JVM GC 次數 JVM GC 耗時 堆內、堆外內存使用量 Tomcat 線程池活躍線程數 ...... 更多壓測時需要關注的指標 ， 見壓測指標[2

相關經驗推薦