Heim > Artikel > Backend-Entwicklung > Dewu-Client-Live-Übertragungsraum APM-Stresstestpraxis
Mit der rasanten Entwicklung der Live-Übertragungsbranche engagieren sich immer mehr Unternehmen in diesem Bereich. Die Stabilität und das Benutzererlebnis des Live-Übertragungsraums sind zu wichtigen Faktoren im Wettbewerb der Live-Übertragungsplattformen geworden. Da der Live-Übertragungsraum jedoch viele komplexe technische Zusammenhänge wie Videoübertragung, Netzwerkkommunikation, Datenverarbeitung usw. umfasst, ist der Leistungsstresstest des Live-Übertragungsraums besonders wichtig. In der Praxis von Stresstests in Live-Übertragungsräumen von Kunden ist die APM-Stresstesttechnologie eine häufig verwendete Leistungstestmethode. Durch Echtzeitüberwachung und -diagnose der Anwendungsleistung können Leistungsengpässe schnell lokalisiert und behoben werden, und die Stabilität der Live-Übertragung wird verbessert Übertragungsraum und Benutzererfahrung verbessert werden.
Es ist ersichtlich, dass APM-Stresstests sehr wichtig sind, um die Stabilität des Live-Übertragungsraums sicherzustellen, die Benutzererfahrung zu verbessern, Systemengpässe zu entdecken und die Systemleistung zu optimieren.
Zusammenfassend lässt sich sagen, dass durch Stresstestmethoden wie Lasttests, Bandbreitentests, Leistungstests, Sicherheitstests und Zuverlässigkeitstests die Leistung, Stabilität, Sicherheit und Zuverlässigkeit des Live-Übertragungsraums umfassend bewertet werden können, um dies sicherzustellen Der Live-Übertragungsraum kann die Bedürfnisse und Erwartungen der Benutzer erfüllen.
Die wichtigsten Stresstestmethoden, die im Dewu Live Broadcast Room verwendet werden, sind Belastungstests und Leistungstests.
Zuallererst ist unser Stresstestziel [IM-Leistungsstresstest basierend auf Live-Übertragungsräumen]. Der Client empfängt über einen längeren Zeitraum eine große Anzahl von IM-Nachrichten. Treten Leistungsprobleme wie Verzögerungen, Abstürze oder OOM auf? Führen Sie vor jeder Veröffentlichung eine Runde Stresstests durch, um Leistungsprobleme im Offline-Live-Übertragungsraum im Voraus aufzudecken und zu verhindern, dass Leistungsprobleme online übertragen werden.
In Bezug auf spezifische Stresstestmethoden hoffen wir, die folgenden Bedingungen zu erfüllen:
Basierend auf den oben genannten Anforderungen und der Erkundung der Stresstestmethode hat unser Live-Broadcast-Geschäftsteam diese durchlaufen die folgenden drei Phasen: #🎜 🎜#
4. Stresstestphase4.1 Die erste PhaseDie Methode, die in verwendet wird Die erste Phase des Stresstests im Live-Übertragungsraum. Es ist relativ einfach, ein Skript zu verwenden, um zu simulieren, dass Benutzer Kommentare, Likes usw. an den Raum senden, der einem Stresstest unterzogen werden muss. Sie müssen den entsprechenden Python-Code selbst schreiben und die entsprechende IM-Nachricht an einen Live-Übertragungsraum senden. Folgendes ist Teil des Python-Skripts:
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
#🎜🎜 #
Der Hauptprozess ist wie folgt:#🎜 🎜## 🎜🎜#
Der so implementierte Stresstest ist relativ einfach und kann auch einige wichtige IM-Nachrichten abdecken, weist aber auch einige offensichtliche Mängel auf:
# 🎜 🎜# Um einen Live-Übertragungsraum einem Stresstest zu unterziehen, müssen Sie die Raum-ID oder das IM-Thema kennen. Um diese Informationen zu erhalten, müssen Sie Pakete erfassen oder die Übertragungsaufzeichnung überprüfen, was ziemlich mühsam ist.
Dann teilt die Anpassungsschnittstelle dem Backend auf dieser Basis mit, dass ein Stress vorliegt Testen Sie den erforderlichen Raum und lassen Sie dann das Backend das Skript der ersten Stufe aufrufen, um den entsprechenden Raum einem Stresstest zu unterziehen.
Diese Methode macht das manuelle Abrufen der Raum-ID überflüssig. Bei der Erstellung dieser visuellen Mock-Plattform wurde die Funktion von Mock-IM hinzugefügt, die wenig mit Stresstests zu tun hat. Sie ist im Wesentlichen dieselbe wie die durch Skripte implementierte Stresstestmethode.
4.3 Die dritte PhaseDiese Phase löst die oben genannten verbleibenden Probleme der Nachrichtentypabdeckung mit Funktionsiteration und gleichzeitig z weitere Befreiung Manueller Eingriff, basierend auf der Teslalab-Automatisierungsplattform, verwendet UI-Skripte, um unsere Stresstestfunktion regelmäßig auszuführen und so eine wirklich automatisierte Stresstestfunktion zu realisieren. Die spezifischen Vorgänge jedes Schritts werden unten erläutert Jeder zusätzliche IM-Nachrichtentyp verfügt über eine entsprechende Entitätsklasse. Diese Klassen erben alle von der Basisklasse BaseLiveChatMessage, daher haben wir BaseLiveChatMessage eine abstrakte Schnittstellenmethode hinzugefügt, um diesen Nachrichtentyp zu generieren.
那么我们在新加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消息的覆盖率和可维护性也得到了保证。
在现有的基础上,为了使得压测更加自动化,我们接入了Teslab自动化测试平台,可以定时启动自动化UI脚本,提升压测效率,自动化脚本是基于UiAutomator,语法非常简易,维护成本很低。
综上,第三阶段的压测策略通过客户端发起的方式,实现了IM压测使用方式方便、支持多设备压测和压测指标有记录的目标。同时,我们还需要在实际实施过程中不断优化和改进,以进一步提高压测效率和结果的可靠性。
压测流程图:
压测只是一个手段,最重要的是发现问题,解决问题,通过三个阶段的压测也发现了不少问题。
Durch drei Stresstestphasen hat das Team einige iOS-Probleme erfolgreich entdeckt und gelöst. Das Wichtigste dabei ist, dass die CPU ungewöhnlich hoch war und die Schnittstelle hängen blieb, wenn der Stresstest länger als 20 Minuten dauerte. Nach einer Untersuchung wurde festgestellt, dass das Problem auf die Verteilung von Nachrichten nacheinander an die Geschäftsschicht zurückzuführen war, was zu einer übermäßigen CPU-Auslastung und zu häufigen Aktualisierungen der Benutzeroberfläche (bis zu Dutzenden Mal pro Sekunde) führte. Um dieses Problem anzugehen, hat das Team zwei Lösungen angenommen: Eine besteht darin, Nachrichtengruppen über Timer an die Geschäftsschicht zu verteilen, anstatt Nachrichten einzeln zu verteilen, und die andere darin, einen Threadwechsel innerhalb des Timers durchzuführen, um sicherzustellen, dass es nur einen Threadwechsel gibt innerhalb eines Zeitraums.
Darüber hinaus entdeckte das Team auch die OOM-Situation, die durch die kontinuierliche Erhöhung des Speichers während des Stresstests verursacht wurde. Der Grund dafür ist, dass einige IMs nur einmal in einem bestimmten Zeitraum ausgeführt werden In Situationen mit hoher Parallelität wird es sich weiterhin ansammeln und einen Speicherüberlauf verursachen. Um dieses Problem zu lösen, hat das Team eine Optimierungslösung für die Animationsausführung eingeführt, um einen Speicherüberlauf zu vermeiden.
Darüber hinaus entdeckte das Team durch die Kylin-Komponente mehrere Speicherleckprobleme und löste sie rechtzeitig, um die Stabilität und Zuverlässigkeit der Live-Übertragungsanwendung sicherzustellen. Kurz gesagt: Durch die drei Phasen des Stresstests konnte das Team mehrere Probleme erfolgreich entdecken und lösen, was nicht nur die Leistung und Stabilität der Anwendung verbesserte, sondern auch nützliche Erfahrungen und Inspiration für die Technologieakkumulation und -entwicklung des Teams lieferte.
Leistungsstresstests sind zwar ein wichtiges Mittel, um den stabilen und effizienten Betrieb des Live-Übertragungsraums sicherzustellen, aber wir können dies nicht als das Ende der Codeentwicklung betrachten. Guter Code sollte vom gesamten Team wartbar sein. Die Lesbarkeit, Wartbarkeit und Skalierbarkeit des Codes sind gleichermaßen wichtig. Nur durch die kontinuierliche Fokussierung auf Codequalität und Teamzusammenarbeit während des Entwicklungs- und Wartungsprozesses kann der Live-Übertragungsraum den Benutzern weiterhin qualitativ hochwertige Dienste bieten.
Bei der Durchführung von Leistungsbelastungstests im Live-Übertragungsraum müssen Sie auch auf die Lesbarkeit und Wartbarkeit des Codes achten. Wir sollten einen strengen Codeüberprüfungsmechanismus zur Überwachung und Kontrolle der Codequalität einrichten, um die Zuverlässigkeit und Skalierbarkeit des Codes sicherzustellen. Gleichzeitig konzentrieren wir uns auf die Teamzusammenarbeit und etablieren einen Kommunikations- und Kooperationsmechanismus innerhalb des Teams, damit die Teammitglieder gemeinsam den Live-Übertragungsraum pflegen und ein besseres Benutzererlebnis bieten können.
Das obige ist der detaillierte Inhalt vonDewu-Client-Live-Übertragungsraum APM-Stresstestpraxis. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!