得物客戶直播間APM壓測實踐

一、背景

隨著直播產業的快速發展，越來越多的企業涉足這一領域，直播間的穩定性和用戶體驗成為了直播平台競爭的重要因素。但是，由於直播間涉及多個複雜的技術環節，如視訊傳輸、網路通訊、資料處理等，因此直播間的效能壓測顯得尤為重要。在客戶端直播間的壓測實務中，APM壓測技術是一種常用的效能測試方法，透過對應用程式的效能進行即時監控和診斷，可以快速定位和解決效能瓶頸，提升直播間的穩定性和使用者體驗。

APM壓測的重要性

1. 偵測系統的穩定性：APM壓力測試可以幫助測試人員評估直播間在高並發情況下的效能和穩定性，以確保系統能夠正常運行，並且不會崩潰或故障。
2. 提升使用者體驗：高APM值通常表示直播間可以流暢地處理更多的操作，進而提升使用者的體驗。如果APM值較低，則可能會導致使用者在直播間遇到卡頓和延遲，影響使用者的使用體驗。
3. 發現系統瓶頸：APM壓測可以幫助測試人員和開發人員發現系統的瓶頸和問題，從而可以針對性地進行最佳化和改進。例如，如果在APM壓測中發現了資料庫讀寫效能的問題，可以透過升級資料庫或採用其他最佳化措施來提高系統的效能。
4. 優化系統效能：透過APM壓測，開發人員可以識別系統的效能問題並針對性地進行最佳化。例如，可以採用負載平衡技術來分散流量，採用快取技術來減少資料庫負載，或採用非同步處理來提高系統的並發能力。

由此可知，APM壓測對於確保現場的穩定性、提升使用者體驗、發現系統瓶頸和最佳化系統效能都非常重要。

二、直播間常見的壓測方式

1. 負載測試：透過模擬大量使用者存取直播間，測試直播間在高並發情況下的性能和穩定性。可以使用工具如JMeter或LoadRunner等來模擬使用者請求，以便評估直播間在不同負載下的表現。
2. 頻寬測試：直播間需要確保足夠的頻寬來支援高畫質視訊的即時傳輸，因此需要進行頻寬測試以確保直播間具備足夠的頻寬。可以使用網速測試工具來評估頻寬的實際頻寬和穩定性。
3. 效能測試：透過模擬不同場景下的使用者訪問，測試直播間在不同場景下的表現表現，例如同時觀看直播、同時發送彈幕等情況。可以使用效能測試工具如WebLOAD等來模擬並發請求，以便評估直播間在不同場景下的效能表現。
4. 安全測試：直播間需要確保使用者資訊和隱私的安全，因此需要進行安全測試以確保直播間沒有安全漏洞。可使用工具如Burp Suite等進行滲透測試，以評估直播間的安全性。
5. 可靠性測試：透過模擬不同的故障和異常情況，測試直播間在異常情況下的表現和復原力。可以使用工具如Chaos Monkey等模擬異常情況，以評估直播間的可靠性和恢復能力。

綜上所述，透過負載測試、頻寬測試、效能測試、安全測試和可靠性測試等壓測方式，可以全面評估直播間的效能、穩定性、安全性和可靠性，從而確保直播間能夠滿足使用者的需求和期望。

得物直播間主要採用的壓測方式是負載測試、效能測試。

三、實現方式

首先我們壓測的目標是【基於直播間的IM效能壓測】，壓測的主要目的是監測當客戶端某個直播間長時間接收到大量IM訊息的時候，是否會出現卡頓、crash或OOM等效能問題。在每次發版前跑一輪壓測，提前在線下暴露直​​播間的性能問題，避免性能問題被帶到線上。

在具體的壓測手段上我們希望能夠滿足以下幾個條件：

#

1. 盡量覆寫更多的IM訊息類型
2. 壓測自動化程度高，省去較多的手動操作麻煩
3. #維護成本低
4. 壓測盡量不依賴服務端，能夠直接實作本機上的訊息壓測

基於上述幾點要求，在探索壓測的方式，我們直播業務組大概經歷了以下三個階段：

四、壓測階段

4.1   第一階段

直播間壓測的第一階段採用的方式比較簡單，透過腳本模擬使用者發送評論、按讚等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訊息，但也有幾個比較明顯的缺點：

1. #壓測某個直播間，需要知道房間的ID或是IM的topic，取得這個資訊就要去抓包或查開播紀錄，比較麻煩。
2. 客戶端程式碼每次新增一個IM訊息就需要去手動維護python腳本去新加對應的IM號，對於後期的維護有一定的要求，需要維護的同學會寫python，並且在後續的需求維護者要主動了解每個版本迭代新加的IM訊息，主動去更新腳本的IM訊息類型，這一塊無疑增加了比較大的維護成本。

4.2   第二階段

在本階段著重於解決上個階段遺留下來的問題，針對取得房間ID的問題，這個只需要後端提供對應的開播清單介面即可，問題是如何使得壓測這個流程操作起來更方便？這裡我們就想到了視覺化，滑鼠點一下就能壓測豈不是非常簡單！於是我們基於前端技術，使用Vue3搭建了一個簡易的IM訊息操作頁面，可以在這個視覺化介面選擇自己想要發送的房間和IM號，並且在做這個工具的同時豐富了IM訊息發送的一些邏輯，可以針對訊息優先順序、房間訊息還是全站訊息做了個人化處理，順便為IM的mock調試做了一些工作。

然後在這個基礎上，調諧介面告訴後端需要壓測的房間，再讓後端去調用第一階段的腳本去壓測對應的房間。

該方式省去了之前需要自己去手動取得房間ID的麻煩，並且在做這個視覺化Mock平台的時候加入了mock IM的功能和壓測關係不大，本質上和腳本實現的壓測方式並無差別。

4.3   第三階段

這個階段解決了上面遺留的隨著功能迭代，訊息類型覆蓋的問題，同時為了進一步解放人工介入，基於Teslab自動化平台，用UI腳本的方式定時去跑我們的壓測功能，實現了真正的自動化壓測功能。以下分別解釋每個步驟的特定操作

4.3.1  訊息類型覆蓋

在客戶端每個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消息的覆盖率和可维护性也得到了保证。

4.3.2  自动化

在现有的基础上，为了使得压测更加自动化，我们接入了Teslab自动化测试平台，可以定时启动自动化UI脚本，提升压测效率，自动化脚本是基于UiAutomator，语法非常简易，维护成本很低。

1. 客户端内部备齐所有的IM压测类型。在进行IM压测时，客户端应当支持各种类型的IM消息，例如文本消息、语音消息、得物客戶直播間APM壓測實踐消息、礼物消息等等。同时，客户端还应当支持各种不同的IM操作，如点赞、评论、送礼等，以全面测试IM功能的稳定性和性能。
2. 直播debug工具接通了kylin，kylin组件已经打通了amp平台。为了更好地收集和记录压测指标，我们需要将直播debug工具与kylin组件和amp平台进行打通，确保能够快速地收集和分析压测数据。在这个过程中，kylin组件将负责接收客户端发送的压测数据，并将这些数据传递给amp平台进行进一步处理和分析。
3. apm平台收到了直播IM压测记录飞书通知到固定的群。为了及时发现和解决潜在的性能问题，我们需要将压测记录及时通知到相应的人员，例如开发人员、测试人员等。在这个过程中，我们可以利用飞书等即时通讯工具，将压测记录发送到固定的群，以便相关人员及时查看并进行分析。

综上，第三阶段的压测策略通过客户端发起的方式，实现了IM压测使用方式方便、支持多设备压测和压测指标有记录的目标。同时，我们还需要在实际实施过程中不断优化和改进，以进一步提高压测效率和结果的可靠性。

压测流程图：

五、压测效果

六、收益

压测只是一个手段，最重要的是发现问题，解决问题，通过三个阶段的压测也发现了不少问题。

透過三個階段的壓測，團隊成功地發現並解決了一些iOS方面的問題。其中，最重要的是發現了壓測時長超過20分鐘時，CPU異常高並伴隨著介面卡死的情況。經過排查，發現問題源自於訊息逐條往業務層分發，導致CPU消耗太大和UI介面刷新太頻繁（每秒鐘刷新大幾十次）。針對這個問題，團隊採取了兩個解決方案：一是透過定時器向業務層分發訊息群組，而不是逐條分發訊息；二是在計時器內部做線程切換，保證在一段時間內只有一次的線程切換。

此外，團隊在壓測過程中也發現了記憶體持續上漲產生的OOM情況，原因是某些IM有動畫執行時間，一段時間內只會執行一次，高並發情況下就會不斷累積導致記憶體溢位。對於這個問題，團隊採取了對動畫執行的最佳化方案，避免了記憶體溢出的情況。

另外，透過kylin元件，團隊也發現了若干記憶體洩漏問題，並及時解決了這些問題，保證了直播應用的穩定性和可靠性。總之，透過三個階段的壓測，團隊成功地發現和解決了多個問題，不僅提升了應用的效能和穩定性，也為團隊的技術累積和發展提供了有益的經驗和啟示。

七、結束語

效能壓測的確是保證直播間穩定、高效運作的重要手段，但我們不能把它看作是程式碼開發的終點。好的程式碼應該是能夠被整個團隊共同維護的，程式碼的可讀性、可維護性和可擴展性同樣重要。只有在開發和維護過程中，不斷注重程式碼品質和團隊協作，才能讓直播間持續為使用者提供優質的服務。

在進行直播間效能壓測的同時，也需要注意程式碼的可讀性和可維護性。我們應該建立嚴格的程式碼審核機制，對程式碼品質進行監控和控制，以確保程式碼的可靠性和可擴展性。同時，注重團隊合作，建立團隊內部溝通與合作的機制，讓團隊成員能共同維護好直播間，提供更好的使用者體驗。

#

以上是得物客戶直播間APM壓測實踐的詳細內容。更多資訊請關注PHP中文網其他相關文章！