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

作者：大勝 Herman 2023-03-31 18:36:00

性能壓測的確是保證直播間穩定、高效運行的重要手段，但我們不能把它看作是代碼開發的終點。好的代碼應該是能夠被整個團隊共同維護的，代碼的可讀性、可維護性和可擴展性同樣重要。

一、背景

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

APM壓測的重要性

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

由此可知，APM壓測對于保證直播間的穩定性、提升用戶體驗、發現系統瓶頸和優化系統性能都非常重要。

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

負載測試：通過模擬大量用戶訪問直播間，測試直播間在高并發情況下的性能和穩定性。可以使用工具如JMeter或LoadRunner等來模擬用戶請求，以便評估直播間在不同負載下的表現。
帶寬測試：直播間需要保證足夠的帶寬來支持高清視頻的實時傳輸，因此需要進行帶寬測試以確保直播間具備足夠的帶寬。可以使用網速測試工具來評估帶寬的實際帶寬和穩定性。
性能測試：通過模擬不同場景下的用戶訪問，測試直播間在不同場景下的性能表現，例如同時觀看直播、同時發送彈幕等情況。可以使用性能測試工具如WebLOAD等來模擬并發請求，以便評估直播間在不同場景下的性能表現。
安全測試：直播間需要保證用戶信息和隱私的安全，因此需要進行安全測試以確保直播間沒有安全漏洞。可以使用工具如Burp Suite等進行滲透測試，以評估直播間的安全性。
可靠性測試：通過模擬不同的故障和異常情況，測試直播間在異常情況下的表現和恢復能力。可以使用工具如Chaos Monkey等來模擬異常情況，以評估直播間的可靠性和恢復能力。

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

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

三、實現方式

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

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

盡量覆蓋更多的IM消息類型
壓測自動化程度高，省去較多的手動操作麻煩
維護成本低
壓測盡量不依賴服務端，能夠直接實現本地端上的消息壓測

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

四、壓測階段

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消息，但是也有幾個比較明顯的缺點：

壓測某個直播間，需要知道房間的ID或者IM的topic，獲取這個信息就要去抓包或者查開播記錄，比較麻煩。
客戶端代碼每次新增一個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，語法非常簡易，維護成本很低。

客戶端內部備齊所有的IM壓測類型。在進行IM壓測時，客戶端應當支持各種類型的IM消息，例如文本消息、語音消息、圖片消息、禮物消息等等。同時，客戶端還應當支持各種不同的IM操作，如點贊、評論、送禮等，以全面測試IM功能的穩定性和性能。
直播debug工具接通了kylin，kylin組件已經打通了amp平臺。為了更好地收集和記錄壓測指標，我們需要將直播debug工具與kylin組件和amp平臺進行打通，確保能夠快速地收集和分析壓測數據。在這個過程中，kylin組件將負責接收客戶端發送的壓測數據，并將這些數據傳遞給amp平臺進行進一步處理和分析。
apm平臺收到了直播IM壓測記錄飛書通知到固定的群。為了及時發現和解決潛在的性能問題，我們需要將壓測記錄及時通知到相應的人員，例如開發人員、測試人員等。在這個過程中，我們可以利用飛書等即時通訊工具，將壓測記錄發送到固定的群，以便相關人員及時查看并進行分析。

綜上，第三階段的壓測策略通過客戶端發起的方式，實現了IM壓測使用方式方便、支持多設備壓測和壓測指標有記錄的目標。同時，我們還需要在實際實施過程中不斷優化和改進，以進一步提高壓測效率和結果的可靠性。

壓測流程圖：

五、壓測效果

六、收益

壓測只是一個手段，最重要的是發現問題，解決問題，通過三個階段的壓測也發現了不少問題。

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

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

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

七、結束語

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

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

責任編輯：武曉燕來源：得物技術

性能壓測代碼