在遊戲陪玩系統開發中，如何進行效能測試？

前言

談起遊戲陪玩系統開發中的效能測試，大家經常聊的是高併發、高可用、效能優化、全鏈路壓測等Topic，聽起來都挺高大上，但這些概念追本溯源，還是要落到效能測試基礎的東西上。比如遊戲陪玩系統開發的需求分析、場景建模、測試方案、效能分層、指標監控、結果評估和優化本身上面。這篇文章，整理了基礎部分的一些知識和我自己的思考，供大家參考。

思維導圖

知識體系

基礎指標

簡單來說，遊戲陪玩系統開發中的效能測試實際上主要關注如下三點：

• 速度：TPS、RT ；
• 容量：吞吐量、PV、Hit；
• 資源：CPU、Memory、DiskIO、Network、檔案控制程式碼數；

效能分層

遊戲陪玩系統開發的效能測試領域，要在評估調研階段就考慮效能分層的影響。在效能分析和優化階段，也要考慮不同層級對整體效能的影響。我將它們分為如下六層：

• 網路層：主要指頻寬、網段、防火牆等設施，當然，CND之類的資源，也可以劃分在這一領域；
• 閘道器層：閘道器是請求入口和業務接入層，一般登入驗籤呼叫、加解密鑑權、限流等操作，都是在閘道器進行；
• 應用層：無論是遊戲陪玩系統開發前端的渲染展示還是後端的邏輯處理，都可以理解為應用層；
• 中介軟體：中介軟體包含快取、MQ、JOB、DTS/DRC/DAL、配置中心等一系列元件；
• 儲存層：一般指資料儲存和檔案儲存層級，典型的元件有MySQL、HDFS；
• 物理層：無論是雲服務還是自建機房，物理硬體層面都可以歸納到這一層；

需求調研

• 專案背景

版本迭代&獨立專案&新建服務&系統重構&效能優化；

• 測試目的

超賣&高併發&擴容性&配置驗證&資源耗用；

• 系統架構

技術架構：遊戲陪玩系統開發中服務間的依賴關係，包含快取，MQ等資訊；

網路拓撲：請求-域名-SLB/HA/Nginx-web-app-DB以及外部依賴；

• 場景模型

業務場景：遊戲陪玩系統開發的業務場景的多樣性和特殊性以及對指令碼開發聯調&資料預埋的影響；

業務模型：只讀、讀寫、批處理、定時Job；

業務配比：被測場景佔總體場景的業務量佔比（公式：被測場景/總業務量*100%）

•  選取業務峰值的資料，單獨統計；

•  如果各業務佔比類似，則按照比例轉化；

•  如果比例差距大，則按照區間單獨統計分析；

• 環境配置

PRE&PERF、app&Redis&MQ&DB&網路&網段&&頻寬&防火牆，是否獨享資源隔離等；

• 效能指標

業務指標：DAU、GMV、註冊使用者數、線上使用者數、活躍使用者數、增長趨勢等；

系統指標：協議型別、長短連結、同步策略、加解密、JVM記憶體分配、容器執行緒數&連線數&Timeout、MQ-Cousumer數量；

壓測指標：QPS、TPS、ART、99%RT、Success%；

• 資料型別

資料鋪底量；

是否有敏感資料需脫敏；

限制條件(時間&次數&許可權)；

自增、唯一、UUID、加解密、冪等；

• 關鍵時間

提測時間、驗收時間、上線時間；

模型場景

業務模型：遊戲陪玩系統開發的業務場景、流量轉化漏斗；

測試模型：關注核心場景，過濾無關及非核心業務；

場景模型：從系統架構設計層面出發，關注不同層面，提升效能！

•  基準：單機單服務單介面；
•  併發：設定閾值，觀察水位；
•  容量：階梯式加壓、效能拐點、資源瓶頸；
•  異常：容錯處理、監控告警、容災恢復演練；
•  穩定性：遊戲陪玩系統開發長期穩定正確提供服務的能力，可用性SLA；

測試方案

• 專案背景：說明專案開展的背景及目的；
• 測試方案：針對遊戲陪玩系統開發涉及的場景，測試實施的大體方案；
• 實施準則：任何專案，都要有準入準出和暫停中止準則；
• 效能模型：針對遊戲陪玩系統開發具體的場景，設計的效能模型最好經過評估驗證；
• 測試策略：針對測試模型所採用的不同的測試策略，同步的測試策略要達成什麼樣的目的；
• 效能指標：業務指標是多少？轉化的技術指標是多少？冗餘範圍有多大？
• 準備工作：其中包含環境、資料、指令碼、監控等準備事項；
• 組織結構：整個專案中涉及哪些事項？不同事項的負責人是誰？交付時間是什麼時候？

結果評估

在遊戲陪玩系統開發的效能測試實施過程中，準確定義和描述效能測試結果，及針對不同結果進行模型分析，是很重要的一項能力。

• 效能實施方法論

基於指標構建；

建模是分析的過程和結果；

基於真實環境的系統模擬；

壓測實施過程是整體的核心；

需要設定統一的目標、流程、分析方法、組織結構；

• 正確描述效能結果和過程的術語

瓶頸描述：什麼場景執行了什麼策略/操作，因為什麼原因導致了什麼結果；

解決方案：優化了哪裡？驗證的方式及結果？是否滿足預期&是否解決了發現的問題？

• 效能分析層級

業務分級：業務-場景-資料-架構-引數；

技術分級：引擎-網路-應用-中介軟體-資料庫；

•  工具：關注指標，從結果反推過程；

•  配置：執行緒、連線數、Timeout、長短連結、同步非同步、路由轉發；

•  應用：日誌、硬體配置、資源使用率；

•  中介軟體：Job、快取命中、訊息堆積、Consumer配置；

•  資料庫：資源耗用、庫表結構、表鎖行鎖、活躍連線數、最大連線數；

• 效能拐點

TPS增長放緩，RT快速上升；

• 效能交叉點

模型上的TPS和RT交叉節點；

• 效能平衡點

重點關注遊戲陪玩系統開發業務可接受的最大RT；

• 效能衰減點

timeout引數&TPS急劇惡化抖降&RT快速飆升；

指令碼設計

• 什麼時候需要做指令碼關聯？

服務端結果動態返回，非冪等；

response body的引數需要向下透傳；

• 如何理解併發和事務的區別？

併發指的是同一時刻服務端接收到的請求數，而非壓測引擎的併發執行緒/RPS；

• thinktime怎麼用？

它有什麼效果？

是否存在真實的業務場景？

是否影響遊戲陪玩系統開發整體的壓測場景和服務資源？

• 主要關注哪些指標？

併發數、TPS、ART、99%RT、CPU%、Memory%、systemLoad%；

典型特例

• 檔案儲存優化

原理：檔案/圖片儲存在源節點，利用CDN快取各種變更和路徑。CDN未命中，回源節點處理並返回，同時同步最新的變更和路徑到CDN。

優點：節省儲存成本，提高查詢展示渲染效能，靈活滿足業務。

注意事項：遊戲陪玩系統開發大檔案分塊儲存，避免區域性過熱導致單機磁碟IO過載，分塊有助於整體系統資源排程。

本文轉載自網路，轉載僅為分享乾貨知識，如有侵權歡迎聯絡雲豹科技進行刪除處理
原文連結：