一、背景

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

APM壓測的重要性

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

由此可知，APM壓測對于保證直播間的穩(wěn)定性、提升用戶體驗、發(fā)現(xiàn)系統(tǒng)瓶頸和優(yōu)化系統(tǒng)性能都非常重要。

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

1. 負載測試：通過模擬大量用戶訪問直播間，測試直播間在高并發(fā)情況下的性能和穩(wěn)定性?？梢允褂霉ぞ呷鏙Meter或LoadRunner等來模擬用戶請求，以便評估直播間在不同負載下的表現(xiàn)。
2. 帶寬測試：直播間需要保證足夠的帶寬來支持高清視頻的實時傳輸，因此需要進行帶寬測試以確保直播間具備足夠的帶寬。可以使用網(wǎng)速測試工具來評估帶寬的實際帶寬和穩(wěn)定性。
3. 性能測試：通過模擬不同場景下的用戶訪問，測試直播間在不同場景下的性能表現(xiàn)，例如同時觀看直播、同時發(fā)送彈幕等情況。可以使用性能測試工具如WebLOAD等來模擬并發(fā)請求，以便評估直播間在不同場景下的性能表現(xiàn)。
4. 安全測試：直播間需要保證用戶信息和隱私的安全，因此需要進行安全測試以確保直播間沒有安全漏洞?？梢允褂霉ぞ呷鏐urp Suite等進行滲透測試，以評估直播間的安全性。
5. 可靠性測試：通過模擬不同的故障和異常情況，測試直播間在異常情況下的表現(xiàn)和恢復(fù)能力。可以使用工具如Chaos Monkey等來模擬異常情況，以評估直播間的可靠性和恢復(fù)能力。

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

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

三、實現(xiàn)方式

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

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

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

基于上面幾點要求，在探索壓測的方式，我們直播業(yè)務(wù)組大概經(jīng)歷了下面三個階段：

四、壓測階段

4.1   第一階段

直播間壓測的第一階段采用的方式比較簡單，通過腳本模擬用戶發(fā)送評論、點贊等IM到需要壓測的房間。需要自己編寫相應(yīng)的python代碼，發(fā)送相對應(yīng)的IM消息到某個直播間，以下是部分Python腳本的部分內(nèi)容：

class APIUtils:
    """ 僅適用于測試環(huán)境 """


    @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

主要流程如下圖：

這種方式實現(xiàn)的壓測比較簡單，也能覆蓋一些比較重要的IM消息，但是也有幾個比較明顯的缺點：

1. 壓測某個直播間，需要知道房間的ID或者IM的topic，獲取這個信息就要去抓包或者查開播記錄，比較麻煩。
2. 客戶端代碼每次新增一個IM消息就需要去手動維護python腳本去新加對應(yīng)的IM號，對于后期的維護有一定的要求，需要維護的同學(xué)會寫python，并且在后續(xù)的需求維護者要主動了解每個版本迭代新加的IM消息，主動去更新腳本的IM消息類型，這一塊無疑增加了比較大的維護成本。

4.2   第二階段

在本階段著重于解決上個階段遺留下來的問題，針對獲取房間ID的問題，這個只需要后端提供相應(yīng)的開播列表接口即可，問題是如何使得壓測這個流程操作起來更方便？這里我們就想到了可視化，鼠標點一下就能壓測豈不是非常簡單！于是我們基于前端技術(shù)，使用Vue3搭建了一個簡易的IM消息操作頁面，可以在這個可視化界面選擇自己想要發(fā)送的房間和IM號，并且在做這個工具的同時豐富了IM消息發(fā)送的一些邏輯，可以針對消息優(yōu)先級、房間消息還是全站消息做了個性化處理，順便為IM的mock調(diào)試做了一些工作。

然后在這個基礎(chǔ)上，調(diào)接口告訴后端需要壓測的房間，再讓后端去調(diào)用第一階段的腳本去壓測相應(yīng)的房間。

該方式省去了之前需要自己去手動獲取房間ID的麻煩，并且在做這個可視化Mock平臺的時候加入了mock IM的功能和壓測關(guān)系不大，本質(zhì)上和腳本實現(xiàn)的壓測方式并無區(qū)別。

4.3   第三階段

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

4.3.1  消息類型覆蓋

在客戶端每個IM消息類型，都有一個對應(yīng)的IM消息Java類，每增加一個IM消息類型，都會有一個實體類去對應(yīng)，這些類都繼承于基類BaseLiveChatMessage，因此我們在BaseLiveChatMessage里面加了一個接口抽象方法，用于產(chǎn)生此消息類型的mock數(shù)據(jù)。

那么我們在新加IM數(shù)據(jù)的時候，繼承BaseLiveChatMessage，就需要強制覆蓋這個方法，去生成自己的mock消息，非常好的解決了維護性的問題，因為不覆蓋這個mock方法是無法通過編譯的。

下面是警告消息和抽獎消息的Mock代碼：

有了上面的基礎(chǔ)，在測試工程里面加一個IMTest測試類，主要邏輯是掃描所有繼承BaseLiveChatMessage類的子類，然后反射構(gòu)造函數(shù)，調(diào)用mock接口即可獲取到相應(yīng)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) //發(fā)送IM
}

之后的壓測就是控制發(fā)送頻率、壓測時間即可實現(xiàn)本地的壓測，無需依賴服務(wù)端實現(xiàn)。

到此為止，基本已經(jīng)解決了文章最開始的幾個問題，IM消息的覆蓋率和可維護性也得到了保證。

4.3.2  自動化

在現(xiàn)有的基礎(chǔ)上，為了使得壓測更加自動化，我們接入了Teslab自動化測試平臺，可以定時啟動自動化UI腳本，提升壓測效率，自動化腳本是基于UiAutomator，語法非常簡易，維護成本很低。

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

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

壓測流程圖：

五、壓測效果

六、收益

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

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

此外，團隊還在壓測過程中發(fā)現(xiàn)了內(nèi)存持續(xù)上漲產(chǎn)生的OOM情況，原因是某些IM有動畫執(zhí)行時間，一段時間內(nèi)只會執(zhí)行一次，高并發(fā)情況下就會不斷累積導(dǎo)致內(nèi)存溢出。對于這個問題，團隊采取了對動畫執(zhí)行的優(yōu)化方案，避免了內(nèi)存溢出的情況。

另外，通過kylin組件，團隊還發(fā)現(xiàn)了若干內(nèi)存泄漏問題，并及時解決了這些問題，保證了直播應(yīng)用的穩(wěn)定性和可靠性?？傊?，通過三個階段的壓測，團隊成功地發(fā)現(xiàn)和解決了多個問題，不僅提升了應(yīng)用的性能和穩(wěn)定性，也為團隊的技術(shù)積累和發(fā)展提供了有益的經(jīng)驗和啟示。

七、結(jié)束語

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

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