得物客戶端直播間APM壓測實(shí)踐

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

性能壓測的確是保證直播間穩(wěn)定、高效運(yùn)行的重要手段，但我們不能把它看作是代碼開發(fā)的終點(diǎn)。好的代碼應(yīng)該是能夠被整個(gè)團(tuán)隊(duì)共同維護(hù)的，代碼的可讀性、可維護(hù)性和可擴(kuò)展性同樣重要。

一、背景

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

APM壓測的重要性

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

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

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

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

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

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

三、實(shí)現(xiàn)方式

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

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

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

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

四、壓測階段

4.1 第一階段

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

主要流程如下圖：

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

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

4.2 第二階段

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

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

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

4.3 第三階段

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

4.3.1 消息類型覆蓋

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

那么我們在新加IM數(shù)據(jù)的時(shí)候，繼承BaseLiveChatMessage，就需要強(qiáng)制覆蓋這個(gè)方法，去生成自己的mock消息，非常好的解決了維護(hù)性的問題，因?yàn)椴桓采w這個(gè)mock方法是無法通過編譯的。

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

有了上面的基礎(chǔ)，在測試工程里面加一個(gè)IMTest測試類，主要邏輯是掃描所有繼承BaseLiveChatMessage類的子類，然后反射構(gòu)造函數(shù)，調(diào)用mock接口即可獲取到相應(yīng)IM類的mock消息實(shí)體，偽代碼如下：

//獲取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ā)送頻率、壓測時(shí)間即可實(shí)現(xiàn)本地的壓測，無需依賴服務(wù)端實(shí)現(xiàn)。

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

4.3.2 自動化

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

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

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

壓測流程圖：

五、壓測效果

六、收益

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

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

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

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

七、結(jié)束語

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

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

責(zé)任編輯：武曉燕來源：得物技術(shù)