建站
咨詢
售后
建站咨詢
新聞中心
一、背景
隨著直播行業(yè)的飛速發(fā)展，越來(lái)越多的企業(yè)涉足這一領(lǐng)域，直播間的穩(wěn)定性和用戶體驗(yàn)成為了直播平臺(tái)競(jìng)爭(zhēng)的重要因素。但是，由于直播間涉及到多個(gè)復(fù)雜的技術(shù)環(huán)節(jié)，如視頻傳輸、網(wǎng)絡(luò)通訊、數(shù)據(jù)處理等，因此直播間的性能壓測(cè)顯得尤為重要。在客戶端直播間的壓測(cè)實(shí)踐中，APM壓測(cè)技術(shù)是一種常用的性能測(cè)試方法，通過(guò)對(duì)應(yīng)用程序的性能進(jìn)行實(shí)時(shí)監(jiān)控和診斷，可以快速定位和解決性能瓶頸，提升直播間的穩(wěn)定性和用戶體驗(yàn)。
創(chuàng)新互聯(lián)建站是一家專注于網(wǎng)站設(shè)計(jì)、成都網(wǎng)站設(shè)計(jì)與策劃設(shè)計(jì),鄄城網(wǎng)站建設(shè)哪家好?創(chuàng)新互聯(lián)建站做網(wǎng)站,專注于網(wǎng)站建設(shè)十余年,網(wǎng)設(shè)計(jì)領(lǐng)域的專業(yè)建站公司;建站業(yè)務(wù)涵蓋:鄄城等地區(qū)。鄄城做網(wǎng)站價(jià)格咨詢:13518219792
APM壓測(cè)的重要性
- 檢測(cè)系統(tǒng)的穩(wěn)定性：APM壓測(cè)可以幫助測(cè)試人員評(píng)估直播間在高并發(fā)情況下的性能和穩(wěn)定性，以確保系統(tǒng)能夠正常運(yùn)行，并且不會(huì)崩潰或出現(xiàn)故障。
- 提升用戶體驗(yàn)：高APM值通常表示直播間可以流暢地處理更多的操作，從而提高用戶的體驗(yàn)。如果APM值較低，則可能會(huì)導(dǎo)致用戶在直播間中遇到卡頓和延遲，影響用戶的使用體驗(yàn)。
- 發(fā)現(xiàn)系統(tǒng)瓶頸：APM壓測(cè)可以幫助測(cè)試人員和開(kāi)發(fā)人員發(fā)現(xiàn)系統(tǒng)的瓶頸和問(wèn)題，從而可以針對(duì)性地進(jìn)行優(yōu)化和改進(jìn)。例如，如果在APM壓測(cè)中發(fā)現(xiàn)了數(shù)據(jù)庫(kù)讀寫(xiě)性能的問(wèn)題，可以通過(guò)升級(jí)數(shù)據(jù)庫(kù)或者采用其他優(yōu)化措施來(lái)提高系統(tǒng)的性能。
- 優(yōu)化系統(tǒng)性能：通過(guò)APM壓測(cè)，開(kāi)發(fā)人員可以識(shí)別系統(tǒng)的性能問(wèn)題并針對(duì)性地進(jìn)行優(yōu)化。例如，可以采用負(fù)載均衡技術(shù)來(lái)分散流量，采用緩存技術(shù)來(lái)減少數(shù)據(jù)庫(kù)負(fù)載，或者采用異步處理來(lái)提高系統(tǒng)的并發(fā)能力。
由此可知，APM壓測(cè)對(duì)于保證直播間的穩(wěn)定性、提升用戶體驗(yàn)、發(fā)現(xiàn)系統(tǒng)瓶頸和優(yōu)化系統(tǒng)性能都非常重要。
二、直播間常見(jiàn)的壓測(cè)方式
- 負(fù)載測(cè)試：通過(guò)模擬大量用戶訪問(wèn)直播間，測(cè)試直播間在高并發(fā)情況下的性能和穩(wěn)定性?？梢允褂霉ぞ呷鏙Meter或LoadRunner等來(lái)模擬用戶請(qǐng)求，以便評(píng)估直播間在不同負(fù)載下的表現(xiàn)。
- 帶寬測(cè)試：直播間需要保證足夠的帶寬來(lái)支持高清視頻的實(shí)時(shí)傳輸，因此需要進(jìn)行帶寬測(cè)試以確保直播間具備足夠的帶寬?？梢允褂镁W(wǎng)速測(cè)試工具來(lái)評(píng)估帶寬的實(shí)際帶寬和穩(wěn)定性。
- 性能測(cè)試：通過(guò)模擬不同場(chǎng)景下的用戶訪問(wèn)，測(cè)試直播間在不同場(chǎng)景下的性能表現(xiàn)，例如同時(shí)觀看直播、同時(shí)發(fā)送彈幕等情況。可以使用性能測(cè)試工具如WebLOAD等來(lái)模擬并發(fā)請(qǐng)求，以便評(píng)估直播間在不同場(chǎng)景下的性能表現(xiàn)。
- 安全測(cè)試：直播間需要保證用戶信息和隱私的安全，因此需要進(jìn)行安全測(cè)試以確保直播間沒(méi)有安全漏洞?？梢允褂霉ぞ呷鏐urp Suite等進(jìn)行滲透測(cè)試，以評(píng)估直播間的安全性。
- 可靠性測(cè)試：通過(guò)模擬不同的故障和異常情況，測(cè)試直播間在異常情況下的表現(xiàn)和恢復(fù)能力?？梢允褂霉ぞ呷鏑haos Monkey等來(lái)模擬異常情況，以評(píng)估直播間的可靠性和恢復(fù)能力。
綜上所述，通過(guò)負(fù)載測(cè)試、帶寬測(cè)試、性能測(cè)試、安全測(cè)試和可靠性測(cè)試等壓測(cè)方式，可以全面評(píng)估直播間的性能、穩(wěn)定性、安全性和可靠性，從而確保直播間能夠滿足用戶的需求和期望。
得物直播間主要采用的壓測(cè)方式是負(fù)載測(cè)試、性能測(cè)試。
三、實(shí)現(xiàn)方式
首先我們壓測(cè)的目標(biāo)是【基于直播間的IM性能壓測(cè)】，壓測(cè)的主要目的是監(jiān)測(cè)當(dāng)客戶端某個(gè)直播間長(zhǎng)時(shí)間接收到大量IM消息的時(shí)候，是否會(huì)出現(xiàn)卡頓、crash或者OOM等性能問(wèn)題。在每次發(fā)版前跑一輪壓測(cè)，提前在線下暴露直播間的性能問(wèn)題，避免性能問(wèn)題被帶到線上。
在具體的壓測(cè)手段上我們希望能夠滿足以下幾個(gè)條件：
- 盡量覆蓋更多的IM消息類型
- 壓測(cè)自動(dòng)化程度高，省去較多的手動(dòng)操作麻煩
- 維護(hù)成本低
- 壓測(cè)盡量不依賴服務(wù)端，能夠直接實(shí)現(xiàn)本地端上的消息壓測(cè)
基于上面幾點(diǎn)要求，在探索壓測(cè)的方式，我們直播業(yè)務(wù)組大概經(jīng)歷了下面三個(gè)階段：
四、壓測(cè)階段
4.1 第一階段
直播間壓測(cè)的第一階段采用的方式比較簡(jiǎn)單，通過(guò)腳本模擬用戶發(fā)送評(píng)論、點(diǎn)贊等IM到需要壓測(cè)的房間。需要自己編寫(xiě)相應(yīng)的python代碼，發(fā)送相對(duì)應(yīng)的IM消息到某個(gè)直播間，以下是部分Python腳本的部分內(nèi)容：
class APIUtils:
""" 僅適用于測(cè)試環(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):
""" 獲取房間號(hào) """
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)的壓測(cè)比較簡(jiǎn)單，也能覆蓋一些比較重要的IM消息，但是也有幾個(gè)比較明顯的缺點(diǎn)：
- 壓測(cè)某個(gè)直播間，需要知道房間的ID或者IM的topic，獲取這個(gè)信息就要去抓包或者查開(kāi)播記錄，比較麻煩。
- 客戶端代碼每次新增一個(gè)IM消息就需要去手動(dòng)維護(hù)python腳本去新加對(duì)應(yīng)的IM號(hào)，對(duì)于后期的維護(hù)有一定的要求，需要維護(hù)的同學(xué)會(huì)寫(xiě)python，并且在后續(xù)的需求維護(hù)者要主動(dòng)了解每個(gè)版本迭代新加的IM消息，主動(dòng)去更新腳本的IM消息類型，這一塊無(wú)疑增加了比較大的維護(hù)成本。
4.2 第二階段
在本階段著重于解決上個(gè)階段遺留下來(lái)的問(wèn)題，針對(duì)獲取房間ID的問(wèn)題，這個(gè)只需要后端提供相應(yīng)的開(kāi)播列表接口即可，問(wèn)題是如何使得壓測(cè)這個(gè)流程操作起來(lái)更方便？這里我們就想到了可視化，鼠標(biāo)點(diǎn)一下就能壓測(cè)豈不是非常簡(jiǎn)單！于是我們基于前端技術(shù)，使用Vue3搭建了一個(gè)簡(jiǎn)易的IM消息操作頁(yè)面，可以在這個(gè)可視化界面選擇自己想要發(fā)送的房間和IM號(hào)，并且在做這個(gè)工具的同時(shí)豐富了IM消息發(fā)送的一些邏輯，可以針對(duì)消息優(yōu)先級(jí)、房間消息還是全站消息做了個(gè)性化處理，順便為IM的mock調(diào)試做了一些工作。
然后在這個(gè)基礎(chǔ)上，調(diào)接口告訴后端需要壓測(cè)的房間，再讓后端去調(diào)用第一階段的腳本去壓測(cè)相應(yīng)的房間。
該方式省去了之前需要自己去手動(dòng)獲取房間ID的麻煩，并且在做這個(gè)可視化Mock平臺(tái)的時(shí)候加入了mock IM的功能和壓測(cè)關(guān)系不大，本質(zhì)上和腳本實(shí)現(xiàn)的壓測(cè)方式并無(wú)區(qū)別。
4.3 第三階段
這個(gè)階段解決了上面遺留的隨著功能迭代，消息類型覆蓋的問(wèn)題，同時(shí)為了進(jìn)一步解放人工介入，基于Teslab自動(dòng)化平臺(tái)，用UI腳本的方式定時(shí)去跑我們的壓測(cè)功能，實(shí)現(xiàn)了真正的自動(dòng)化壓測(cè)功能。下面分別解釋每個(gè)步驟的具體操作
4.3.1 消息類型覆蓋
在客戶端每個(gè)IM消息類型，都有一個(gè)對(duì)應(yīng)的IM消息Java類，每增加一個(gè)IM消息類型，都會(huì)有一個(gè)實(shí)體類去對(duì)應(yīng)，這些類都繼承于基類BaseLiveChatMessage，因此我們?cè)贐aseLiveChatMessage里面加了一個(gè)接口抽象方法，用于產(chǎn)生此消息類型的mock數(shù)據(jù)。
那么我們?cè)谛录覫M數(shù)據(jù)的時(shí)候，繼承BaseLiveChatMessage，就需要強(qiáng)制覆蓋這個(gè)方法，去生成自己的mock消息，非常好的解決了維護(hù)性的問(wèn)題，因?yàn)椴桓采w這個(gè)mock方法是無(wú)法通過(guò)編譯的。
下面是警告消息和抽獎(jiǎng)消息的Mock代碼：
有了上面的基礎(chǔ)，在測(cè)試工程里面加一個(gè)IMTest測(cè)試類，主要邏輯是掃描所有繼承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
}
之后的壓測(cè)就是控制發(fā)送頻率、壓測(cè)時(shí)間即可實(shí)現(xiàn)本地的壓測(cè)，無(wú)需依賴服務(wù)端實(shí)現(xiàn)。
到此為止，基本已經(jīng)解決了文章最開(kāi)始的幾個(gè)問(wèn)題，IM消息的覆蓋率和可維護(hù)性也得到了保證。
4.3.2 自動(dòng)化
在現(xiàn)有的基礎(chǔ)上，為了使得壓測(cè)更加自動(dòng)化，我們接入了Teslab自動(dòng)化測(cè)試平臺(tái)，可以定時(shí)啟動(dòng)自動(dòng)化UI腳本，提升壓測(cè)效率，自動(dòng)化腳本是基于UiAutomator，語(yǔ)法非常簡(jiǎn)易，維護(hù)成本很低。
- 客戶端內(nèi)部備齊所有的IM壓測(cè)類型。在進(jìn)行IM壓測(cè)時(shí)，客戶端應(yīng)當(dāng)支持各種類型的IM消息，例如文本消息、語(yǔ)音消息、圖片消息、禮物消息等等。同時(shí)，客戶端還應(yīng)當(dāng)支持各種不同的IM操作，如點(diǎn)贊、評(píng)論、送禮等，以全面測(cè)試IM功能的穩(wěn)定性和性能。
- 直播debug工具接通了kylin，kylin組件已經(jīng)打通了amp平臺(tái)。為了更好地收集和記錄壓測(cè)指標(biāo)，我們需要將直播debug工具與kylin組件和amp平臺(tái)進(jìn)行打通，確保能夠快速地收集和分析壓測(cè)數(shù)據(jù)。在這個(gè)過(guò)程中，kylin組件將負(fù)責(zé)接收客戶端發(fā)送的壓測(cè)數(shù)據(jù)，并將這些數(shù)據(jù)傳遞給amp平臺(tái)進(jìn)行進(jìn)一步處理和分析。
- apm平臺(tái)收到了直播IM壓測(cè)記錄飛書(shū)通知到固定的群。為了及時(shí)發(fā)現(xiàn)和解決潛在的性能問(wèn)題，我們需要將壓測(cè)記錄及時(shí)通知到相應(yīng)的人員，例如開(kāi)發(fā)人員、測(cè)試人員等。在這個(gè)過(guò)程中，我們可以利用飛書(shū)等即時(shí)通訊工具，將壓測(cè)記錄發(fā)送到固定的群，以便相關(guān)人員及時(shí)查看并進(jìn)行分析。
綜上，第三階段的壓測(cè)策略通過(guò)客戶端發(fā)起的方式，實(shí)現(xiàn)了IM壓測(cè)使用方式方便、支持多設(shè)備壓測(cè)和壓測(cè)指標(biāo)有記錄的目標(biāo)。同時(shí)，我們還需要在實(shí)際實(shí)施過(guò)程中不斷優(yōu)化和改進(jìn)，以進(jìn)一步提高壓測(cè)效率和結(jié)果的可靠性。
壓測(cè)流程圖：
五、壓測(cè)效果
六、收益
壓測(cè)只是一個(gè)手段，最重要的是發(fā)現(xiàn)問(wèn)題，解決問(wèn)題，通過(guò)三個(gè)階段的壓測(cè)也發(fā)現(xiàn)了不少問(wèn)題。
通過(guò)三個(gè)階段的壓測(cè)，團(tuán)隊(duì)成功地發(fā)現(xiàn)并解決了一些iOS方面的問(wèn)題。其中，最重要的是發(fā)現(xiàn)了壓測(cè)時(shí)長(zhǎng)超過(guò)20分鐘時(shí)，CPU異常高并伴隨著界面卡死的情況。經(jīng)過(guò)排查，發(fā)現(xiàn)問(wèn)題源于消息逐條往業(yè)務(wù)層分發(fā)，導(dǎo)致CPU消耗太大和UI界面刷新太頻繁（每秒鐘刷新大幾十次）。針對(duì)這個(gè)問(wèn)題，團(tuán)隊(duì)采取了兩個(gè)解決方案：一是通過(guò)定時(shí)器向業(yè)務(wù)層分發(fā)消息組，而不是逐條分發(fā)消息；二是在定時(shí)器內(nèi)部做線程切換，保證在一段時(shí)間內(nèi)只有一次的線程切換。
此外，團(tuán)隊(duì)還在壓測(cè)過(guò)程中發(fā)現(xiàn)了內(nèi)存持續(xù)上漲產(chǎn)生的OOM情況，原因是某些IM有動(dòng)畫(huà)執(zhí)行時(shí)間，一段時(shí)間內(nèi)只會(huì)執(zhí)行一次，高并發(fā)情況下就會(huì)不斷累積導(dǎo)致內(nèi)存溢出。對(duì)于這個(gè)問(wèn)題，團(tuán)隊(duì)采取了對(duì)動(dòng)畫(huà)執(zhí)行的優(yōu)化方案，避免了內(nèi)存溢出的情況。
另外，通過(guò)kylin組件，團(tuán)隊(duì)還發(fā)現(xiàn)了若干內(nèi)存泄漏問(wèn)題，并及時(shí)解決了這些問(wèn)題，保證了直播應(yīng)用的穩(wěn)定性和可靠性?？傊?，通過(guò)三個(gè)階段的壓測(cè)，團(tuán)隊(duì)成功地發(fā)現(xiàn)和解決了多個(gè)問(wèn)題，不僅提升了應(yīng)用的性能和穩(wěn)定性，也為團(tuán)隊(duì)的技術(shù)積累和發(fā)展提供了有益的經(jīng)驗(yàn)和啟示。
七、結(jié)束語(yǔ)
性能壓測(cè)的確是保證直播間穩(wěn)定、高效運(yùn)行的重要手段，但我們不能把它看作是代碼開(kāi)發(fā)的終點(diǎn)。好的代碼應(yīng)該是能夠被整個(gè)團(tuán)隊(duì)共同維護(hù)的，代碼的可讀性、可維護(hù)性和可擴(kuò)展性同樣重要。只有在開(kāi)發(fā)和維護(hù)過(guò)程中，不斷注重代碼質(zhì)量和團(tuán)隊(duì)協(xié)作，才能讓直播間持續(xù)地為用戶提供優(yōu)質(zhì)的服務(wù)。
在進(jìn)行直播間性能壓測(cè)的同時(shí)，也需要關(guān)注代碼的可讀性和可維護(hù)性。我們應(yīng)該建立嚴(yán)格的代碼審核機(jī)制，對(duì)代碼質(zhì)量進(jìn)行監(jiān)控和控制，以確保代碼的可靠性和可擴(kuò)展性。同時(shí)，注重團(tuán)隊(duì)協(xié)作，建立團(tuán)隊(duì)內(nèi)部溝通和合作的機(jī)制，讓團(tuán)隊(duì)成員能夠共同維護(hù)好直播間，提供更好的用戶體驗(yàn)。
網(wǎng)站題目：得物客戶端直播間APM壓測(cè)實(shí)踐
網(wǎng)頁(yè)網(wǎng)址：http://www.dlmjj.cn/article/dpjipcg.html
