隨著直播產業的快速發展，越來越多的企業涉足這一領域，直播間的穩定性和用戶體驗成為了直播平台競爭的重要因素。但是，由於直播間涉及多個複雜的技術環節，如視訊傳輸、網路通訊、資料處理等，因此直播間的效能壓測顯得尤為重要。在客戶端直播間的壓測實務中，APM壓測技術是一種常用的效能測試方法，透過對應用程式的效能進行即時監控和診斷，可以快速定位和解決效能瓶頸，提升直播間的穩定性和使用者體驗。
由此可知，APM壓測對於確保現場的穩定性、提升使用者體驗、發現系統瓶頸和最佳化系統效能都非常重要。
綜上所述，透過負載測試、頻寬測試、效能測試、安全測試和可靠性測試等壓測方式，可以全面評估直播間的效能、穩定性、安全性和可靠性，從而確保直播間能夠滿足使用者的需求和期望。
得物直播間主要採用的壓測方式是負載測試、效能測試。
首先我們壓測的目標是【基於直播間的IM效能壓測】，壓測的主要目的是監測當客戶端某個直播間長時間接收到大量IM訊息的時候，是否會出現卡頓、crash或OOM等效能問題。在每次發版前跑一輪壓測，提前在線下暴露直播間的性能問題，避免性能問題被帶到線上。
在具體的壓測手段上我們希望能夠滿足以下幾個條件：
#基於上述幾點要求，在探索壓測的方式，我們直播業務組大概經歷了以下三個階段：
直播間壓測的第一階段採用的方式比較簡單，透過腳本模擬使用者發送評論、按讚等IM到需要壓測的房間。需要自己編寫對應的python程式碼，發送相對應的IM訊息到某個直播間，以下是部分Python腳本的部分內容：
class APIUtils:
""" 仅适用于测试环境 """
@staticmethod
def token(user_id: int):
resp = requests.get('https://xxxx.com', params={'user_id': user_id})
return resp.json().get('token')
@staticmethod
def change_rc_im(user_id: int):
try:
im_info = requests.post(
'http://xxxx.com',
headers={'userId': '1'},
data={'kolUserId': user_id}
)
im_id = im_info.json().get('data', {}).get('list', [{}])[0].get('id', 0)
requests.post(
'http://xxxx.com',
headers={'userId': '1'},
data={'kolUserId': user_id, 'id': im_id}
)
except:
pass
time.sleep(3)
data = {
"startTime": int(time.time()) + 1,
"endTime": int(time.time()) + 600 * 6,
"kolUserId": user_id,
"imSwitch": 1,
"id": 0
}
requests.post('xxxx.com',
headers={'userId': '1'}, data=data)
@staticmethod
def get_topic(user_id: int, room_id: int):
""" 获取房间号 """
headers = {
'POIZON-USERID': str(user_id),
'POIZON-ISGUEST': 'false',
'platform': 'iPhone',
'v': '4.78.0'
}
try:
resp = requests.get('xxxx.com',
headers=headers, params={'roomId': room_id})
return resp.json().get('data').get('room').get('imInfo').get('chatRoomId')
except Exception as e:
raise e主要流程如下圖：
#這種方式實現的壓測比較簡單，也能涵蓋一些比較重要的IM訊息，但也有幾個比較明顯的缺點：
在本階段著重於解決上個階段遺留下來的問題，針對取得房間ID的問題，這個只需要後端提供對應的開播清單介面即可，問題是如何使得壓測這個流程操作起來更方便？這裡我們就想到了視覺化，滑鼠點一下就能壓測豈不是非常簡單！於是我們基於前端技術，使用Vue3搭建了一個簡易的IM訊息操作頁面，可以在這個視覺化介面選擇自己想要發送的房間和IM號，並且在做這個工具的同時豐富了IM訊息發送的一些邏輯，可以針對訊息優先順序、房間訊息還是全站訊息做了個人化處理，順便為IM的mock調試做了一些工作。
然後在這個基礎上，調諧介面告訴後端需要壓測的房間，再讓後端去調用第一階段的腳本去壓測對應的房間。
該方式省去了之前需要自己去手動取得房間ID的麻煩，並且在做這個視覺化Mock平台的時候加入了mock IM的功能和壓測關係不大，本質上和腳本實現的壓測方式並無差別。
這個階段解決了上面遺留的隨著功能迭代，訊息類型覆蓋的問題，同時為了進一步解放人工介入，基於Teslab自動化平台，用UI腳本的方式定時去跑我們的壓測功能，實現了真正的自動化壓測功能。以下分別解釋每個步驟的特定操作
在客戶端每個IM訊息類型，都有一個對應的IM訊息Java類，每增加一個IM訊息類型，都會有一個實體類別去對應，這些類別都繼承於基類BaseLiveChatMessage，因此我們在BaseLiveChatMessage裡面加了一個介面抽象方法，用於產生此訊息類型的mock資料。
那么我们在新加IM数据的时候，继承BaseLiveChatMessage，就需要强制覆盖这个方法，去生成自己的mock消息，非常好的解决了维护性的问题，因为不覆盖这个mock方法是无法通过编译的。
下面是警告消息和抽奖消息的Mock代码：
有了上面的基础，在测试工程里面加一个IMTest测试类，主要逻辑是扫描所有继承BaseLiveChatMessage类的子类，然后反射构造函数，调用mock接口即可获取到相应IM类的mock消息实体，伪代码如下：
//获取BaseLiveChatMessage子类
if (allSubClass == null) {
allSubClass = ClassUtils.getAllSubClass(BaseApplication.getInstance(), BaseLiveChatMessage::class.java)
val iterator = allSubClass?.iterator()
while (iterator?.hasNext() == true) {
val next = iterator.next()
try {
next.getDeclaredMethod("mock", Int::class.java)
} catch (e: NoSuchMethodException) {
}
}
}
// ....
allSubClass?.forEach {
val o = constructorMap[it]?.newInstance() as BaseLiveChatMessage
var message: BaseLiveChatMessage? = null
message = o.mock(0)
justPostIM(message) //发送IM
}之后的压测就是控制发送频率、压测时间即可实现本地的压测，无需依赖服务端实现。
到此为止，基本已经解决了文章最开始的几个问题，IM消息的覆盖率和可维护性也得到了保证。
在现有的基础上，为了使得压测更加自动化，我们接入了Teslab自动化测试平台，可以定时启动自动化UI脚本，提升压测效率，自动化脚本是基于UiAutomator，语法非常简易，维护成本很低。
综上，第三阶段的压测策略通过客户端发起的方式，实现了IM压测使用方式方便、支持多设备压测和压测指标有记录的目标。同时，我们还需要在实际实施过程中不断优化和改进，以进一步提高压测效率和结果的可靠性。
压测流程图：
压测只是一个手段，最重要的是发现问题，解决问题，通过三个阶段的压测也发现了不少问题。
透過三個階段的壓測，團隊成功地發現並解決了一些iOS方面的問題。其中，最重要的是發現了壓測時長超過20分鐘時，CPU異常高並伴隨著介面卡死的情況。經過排查，發現問題源自於訊息逐條往業務層分發，導致CPU消耗太大和UI介面刷新太頻繁（每秒鐘刷新大幾十次）。針對這個問題，團隊採取了兩個解決方案：一是透過定時器向業務層分發訊息群組，而不是逐條分發訊息；二是在計時器內部做線程切換，保證在一段時間內只有一次的線程切換。
此外，團隊在壓測過程中也發現了記憶體持續上漲產生的OOM情況，原因是某些IM有動畫執行時間，一段時間內只會執行一次，高並發情況下就會不斷累積導致記憶體溢位。對於這個問題，團隊採取了對動畫執行的最佳化方案，避免了記憶體溢出的情況。
另外，透過kylin元件，團隊也發現了若干記憶體洩漏問題，並及時解決了這些問題，保證了直播應用的穩定性和可靠性。總之，透過三個階段的壓測，團隊成功地發現和解決了多個問題，不僅提升了應用的效能和穩定性，也為團隊的技術累積和發展提供了有益的經驗和啟示。
效能壓測的確是保證直播間穩定、高效運作的重要手段，但我們不能把它看作是程式碼開發的終點。好的程式碼應該是能夠被整個團隊共同維護的，程式碼的可讀性、可維護性和可擴展性同樣重要。只有在開發和維護過程中，不斷注重程式碼品質和團隊協作，才能讓直播間持續為使用者提供優質的服務。
在進行直播間效能壓測的同時，也需要注意程式碼的可讀性和可維護性。我們應該建立嚴格的程式碼審核機制，對程式碼品質進行監控和控制，以確保程式碼的可靠性和可擴展性。同時，注重團隊合作，建立團隊內部溝通與合作的機制，讓團隊成員能共同維護好直播間，提供更好的使用者體驗。
以上是得物客戶直播間APM壓測實踐的詳細內容。更多資訊請關注PHP中文網其他相關文章！
