Salle de diffusion en direct du client Dewu Pratique des tests de résistance APM

1. Contexte

Avec le développement rapide de l'industrie de la diffusion en direct, de plus en plus d'entreprises sont impliquées dans ce domaine. La stabilité et l'expérience utilisateur de la salle de diffusion en direct sont devenues des facteurs importants dans la concurrence des plateformes de diffusion en direct. Cependant, étant donné que la salle de diffusion en direct implique de nombreux liens techniques complexes, tels que la transmission vidéo, la communication réseau, le traitement des données, etc., le test de résistance des performances de la salle de diffusion en direct est particulièrement important. Dans la pratique des tests de résistance dans les salles de diffusion en direct des clients, la technologie de test de résistance APM est une méthode de test de performances couramment utilisée grâce à la surveillance et au diagnostic en temps réel des performances des applications, les goulots d'étranglement des performances peuvent être rapidement localisés et résolus, ainsi que la stabilité du direct. la salle de diffusion peut être améliorée et l’expérience utilisateur.

L'importance des tests de stress APM

1. Détection de la stabilité du système : les tests de stress APM peuvent aider les testeurs à évaluer les performances et la stabilité de la salle de diffusion en direct dans des conditions de concurrence élevée pour garantir que le système peut fonctionner normalement et ne tombera pas en panne ou mauvais fonctionnement.
2. Améliorer l'expérience utilisateur : une valeur APM élevée signifie généralement que la salle de diffusion en direct peut gérer davantage d'opérations en douceur, améliorant ainsi l'expérience utilisateur. Si la valeur APM est faible, les utilisateurs peuvent rencontrer des blocages et des retards dans la salle de diffusion en direct, affectant ainsi l'expérience utilisateur.
3. Découvrez les goulots d'étranglement du système : les tests de résistance APM peuvent aider les testeurs et les développeurs à découvrir les goulots d'étranglement et les problèmes du système, afin qu'une optimisation et des améliorations ciblées puissent être apportées. Par exemple, si un problème de performances de lecture et d'écriture de la base de données est découvert lors du test de résistance APM, les performances du système peuvent être améliorées en mettant à niveau la base de données ou en prenant d'autres mesures d'optimisation.
4. Optimiser les performances du système : grâce aux tests de résistance APM, les développeurs peuvent identifier les problèmes de performances du système et effectuer des optimisations ciblées. Par exemple, la technologie d'équilibrage de charge peut être utilisée pour disperser le trafic, la technologie de mise en cache peut être utilisée pour réduire la charge de la base de données ou le traitement asynchrone peut être utilisé pour améliorer la simultanéité du système.

On peut voir que les tests de résistance APM sont très importants pour garantir la stabilité de la salle de diffusion en direct, améliorer l'expérience utilisateur, découvrir les goulots d'étranglement du système et optimiser les performances du système.

2. Méthodes de tests de résistance courantes dans les salles de diffusion en direct

1. Tests de charge : testez les performances et la stabilité de la salle de diffusion en direct dans des conditions de concurrence élevée en simulant un grand nombre d'utilisateurs accédant à la salle de diffusion en direct. Vous pouvez utiliser des outils tels que JMeter ou LoadRunner pour simuler les demandes des utilisateurs afin d'évaluer les performances de la salle de diffusion en direct sous différentes charges.
2. Test de bande passante : la salle de diffusion en direct doit garantir une bande passante suffisante pour prendre en charge la transmission en temps réel de la vidéo haute définition. Un test de bande passante est donc nécessaire pour garantir que la salle de diffusion en direct dispose d'une bande passante suffisante. Vous pouvez utiliser des outils de test de vitesse du réseau pour évaluer la bande passante réelle et la stabilité de votre bande passante.
3. Test de performances : en simulant l'accès des utilisateurs dans différents scénarios, testez les performances de la salle de diffusion en direct dans différents scénarios, comme regarder des émissions en direct en même temps, envoyer des barrages en même temps, etc. Vous pouvez utiliser des outils de test de performances tels que WebLOAD pour simuler des demandes simultanées afin d'évaluer les performances de la salle de diffusion en direct dans différents scénarios.
4. Tests de sécurité : la salle de diffusion en direct doit garantir la sécurité des informations et de la confidentialité des utilisateurs. Des tests de sécurité sont donc nécessaires pour garantir qu'il n'y a aucune faille de sécurité dans la salle de diffusion en direct. Vous pouvez utiliser des outils tels que Burp Suite pour effectuer des tests d'intrusion afin d'évaluer la sécurité de la salle de diffusion en direct.
5. Test de fiabilité : en simulant différents défauts et situations anormales, testez les performances et la capacité de récupération de la salle de diffusion en direct dans des circonstances anormales. Des outils tels que Chaos Monkey peuvent être utilisés pour simuler des situations anormales afin d'évaluer la fiabilité et les capacités de récupération de la salle de diffusion en direct.

Pour résumer, grâce à des méthodes de tests de résistance telles que les tests de charge, les tests de bande passante, les tests de performances, les tests de sécurité et les tests de fiabilité, les performances, la stabilité, la sécurité et la fiabilité de la salle de diffusion en direct peuvent être évaluées de manière exhaustive pour garantir le La salle de diffusion en direct peut répondre aux besoins et aux attentes des utilisateurs.

Les principales méthodes de tests de résistance utilisées dans Dewu Live Broadcast Room sont les tests de charge et les tests de performances.

3. Méthode de mise en œuvre

Tout d'abord, notre objectif de test de stress est [Test de stress de performance de messagerie instantanée basé sur une salle de diffusion en direct]. le client reçoit un grand nombre de messages de messagerie instantanée pendant une longue période. Y aura-t-il des problèmes de performances tels qu'un décalage, un crash ou un MOO ? Exécutez une série de tests de résistance avant chaque version pour exposer à l'avance les problèmes de performances dans la salle de diffusion en direct hors ligne afin d'éviter que les problèmes de performances ne soient mis en ligne.

En termes de méthodes de stress tests spécifiques, nous espérons remplir les conditions suivantes :

1. Essayez de couvrir autant de types de messages de messagerie instantanée que possible
2. Le test de pression est hautement automatisé, ce qui évite davantage de problèmes de fonctionnement manuel
3. Faible coût de maintenance
4. Le test de pression ne repose pas sur le serveur car autant que possible, et peut être directement Implémentation des tests de stress des messages sur le terminal local

Sur la base des exigences ci-dessus, tout en explorant la méthode des tests de stress, notre groupe commercial de diffusion en direct est probablement passé par les trois étapes suivantes :

Quatre. Étape du test de stress

4.1 Chapitre Phase un

La première phase du test de stress de la salle de diffusion en direct adopte une méthode relativement simple. Un script est utilisé pour simuler l'envoi de commentaires, de likes, etc. par les utilisateurs. qui doit être soumis à un test de résistance. Vous devez écrire vous-même le code python correspondant et envoyer le message IM correspondant à une salle de diffusion en direct. Ce qui suit fait partie du script 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

Le processus principal est le suivant :

.

Le test de résistance ainsi mis en œuvre est relativement simple et peut également couvrir certains messages de messagerie instantanée importants, mais il présente également plusieurs défauts évidents :

1. Pour tester une salle de diffusion en direct, vous devez savoir l'ID de la salle ou pour les sujets de messagerie instantanée, pour obtenir ces informations, vous devez capturer des paquets ou vérifier les enregistrements de diffusion, ce qui est assez gênant.
2. Chaque fois que le code client ajoute un message IM, il doit maintenir manuellement le script Python pour ajouter le numéro IM correspondant. Il existe certaines exigences pour une maintenance ultérieure. Les étudiants qui ont besoin d'une maintenance peuvent écrire Python, et dans ce qui suit. up Il est nécessaire que les responsables prennent l'initiative de comprendre les nouveaux messages IM ajoutés à chaque itération de version et mettent à jour de manière proactive les types de messages IM du script. Cela augmente sans aucun doute le coût de maintenance.

4.2 La deuxième phase

se concentre sur la résolution des problèmes laissés par la phase précédente. Pour le problème de l'obtention de l'ID de la salle, cela nécessite uniquement que le backend fournisse l'interface de liste de diffusion correspondante. make it Le processus de test de résistance est-il plus pratique ? On pense ici à la visualisation. N’est-il pas très simple de pouvoir réaliser des tests de résistance en un seul clic de souris ? Ainsi, sur la base de la technologie frontale, nous avons utilisé Vue3 pour créer une page d'opération de message IM simple. Vous pouvez sélectionner la salle et le numéro de messagerie instantanée que vous souhaitez envoyer sur cette interface visuelle. Lors de la création de cet outil, nous avons enrichi une certaine logique pour l'envoi de messages IM. Il peut être personnalisé pour la priorité des messages, les messages de salle ou les messages à l'échelle du site, et d'ailleurs, du travail a été effectué pour le débogage des simulations de messagerie instantanée.

Ensuite, sur cette base, l'interface d'ajustement indique au backend les salles qui doivent être testées sous contrainte, puis il est demandé au backend d'appeler le script de la première étape pour tester la salle correspondante.

Cette méthode évite d'avoir à obtenir manuellement l'ID de la salle. Lors de la création de cette plate-forme de simulation visuelle, la fonction de simulation de messagerie instantanée est ajoutée et n'a pas grand-chose à voir avec les tests de stress. Il n'y a aucune différence dans la méthode de test de stress implémentée par le script.

4.3 La troisième phase

Cette phase résout le problème mentionné ci-dessus de la couverture du type de message avec l'itération des fonctions. En même temps, afin de libérer davantage l'intervention manuelle, basée sur la plateforme d'automatisation Teslalab, nous utilisons des scripts d'interface utilisateur. pour exécuter régulièrement notre fonction de mesure de pression réalise une fonction de mesure de pression véritablement automatisée. Les opérations spécifiques de chaque étape sont expliquées respectivement ci-dessous

4.3.1 Couverture des types de messages

Chaque type de message IM sur le client a une classe Java de message IM correspondante. Pour chaque type de message IM supplémentaire, il y aura une classe d'entité. correspondent les unes aux autres. Ces classes héritent toutes de la classe de base BaseLiveChatMessage, nous ajoutons donc une méthode abstraite d'interface à BaseLiveChatMessage pour générer des données fictives de ce type de message.

那么我们在新加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，语法非常简易，维护成本很低。

1. 客户端内部备齐所有的IM压测类型。在进行IM压测时，客户端应当支持各种类型的IM消息，例如文本消息、语音消息、Salle de diffusion en direct du client Dewu Pratique des tests de résistance APM消息、礼物消息等等。同时，客户端还应当支持各种不同的IM操作，如点赞、评论、送礼等，以全面测试IM功能的稳定性和性能。
2. 直播debug工具接通了kylin，kylin组件已经打通了amp平台。为了更好地收集和记录压测指标，我们需要将直播debug工具与kylin组件和amp平台进行打通，确保能够快速地收集和分析压测数据。在这个过程中，kylin组件将负责接收客户端发送的压测数据，并将这些数据传递给amp平台进行进一步处理和分析。
3. apm平台收到了直播IM压测记录飞书通知到固定的群。为了及时发现和解决潜在的性能问题，我们需要将压测记录及时通知到相应的人员，例如开发人员、测试人员等。在这个过程中，我们可以利用飞书等即时通讯工具，将压测记录发送到固定的群，以便相关人员及时查看并进行分析。

综上，第三阶段的压测策略通过客户端发起的方式，实现了IM压测使用方式方便、支持多设备压测和压测指标有记录的目标。同时，我们还需要在实际实施过程中不断优化和改进，以进一步提高压测效率和结果的可靠性。

压测流程图：

五、压测效果

六、收益

压测只是一个手段，最重要的是发现问题，解决问题，通过三个阶段的压测也发现了不少问题。

Grâce à trois étapes de tests de résistance, l'équipe a découvert et résolu avec succès certains problèmes iOS. Parmi eux, le plus important est que lorsque le test de stress a duré plus de 20 minutes, le processeur était anormalement élevé et l'interface était bloquée. Après enquête, il a été constaté que le problème provenait de la distribution des messages un par un vers la couche métier, entraînant une consommation excessive du processeur et des actualisations trop fréquentes de l'interface utilisateur (jusqu'à des dizaines de fois par seconde). Pour résoudre ce problème, l'équipe a adopté deux solutions : l'une consiste à distribuer les groupes de messages à la couche métier via des minuteurs au lieu de distribuer les messages un par un ; l'autre consiste à effectuer une commutation de thread dans le minuteur pour garantir qu'il n'y a qu'un seul changement de thread ; dans un laps de temps.

De plus, l'équipe a également découvert la situation de MOO causée par l'augmentation continue de la mémoire pendant le test de stress. La raison en est que certains messages instantanés ont un temps d'exécution d'animation, qui ne sera exécuté qu'une fois par période. Dans des situations de concurrence élevée, il continuera à s'accumuler et à provoquer un débordement de mémoire. Pour résoudre ce problème, l'équipe a adopté une solution d'optimisation de l'exécution des animations afin d'éviter les débordements de mémoire.

De plus, grâce au composant kylin, l'équipe a également découvert plusieurs problèmes de fuite de mémoire et les a résolus à temps pour assurer la stabilité et la fiabilité de l'application de diffusion en direct. En bref, au cours des trois étapes de tests de résistance, l'équipe a découvert et résolu avec succès de multiples problèmes, ce qui a non seulement amélioré les performances et la stabilité de l'application, mais a également fourni une expérience et une inspiration utiles pour l'accumulation et le développement technologique de l'équipe.

7. Conclusion

Les tests de résistance sont en effet un moyen important pour garantir le fonctionnement stable et efficace de la salle de diffusion en direct, mais nous ne pouvons pas le considérer comme la fin du développement du code. Un bon code doit être maintenable par toute l’équipe. La lisibilité, la maintenabilité et l’évolutivité du code sont tout aussi importantes. Ce n'est qu'en se concentrant continuellement sur la qualité du code et la collaboration des équipes pendant le processus de développement et de maintenance que la salle de diffusion en direct pourra continuer à fournir aux utilisateurs des services de haute qualité.

Lorsque vous effectuez des tests de résistance aux performances dans la salle de diffusion en direct, vous devez également faire attention à la lisibilité et à la maintenabilité du code. Nous devrions établir un mécanisme strict de révision du code pour surveiller et contrôler la qualité du code afin de garantir la fiabilité et l'évolutivité du code. Dans le même temps, nous nous concentrons sur la collaboration en équipe et établissons un mécanisme de communication et de coopération au sein de l'équipe afin que les membres de l'équipe puissent maintenir conjointement la salle de diffusion en direct et offrir une meilleure expérience utilisateur.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!