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.
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.
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.
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 :
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 :
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 eLe 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 :
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.
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
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消息的覆盖率和可维护性也得到了保证。
在现有的基础上，为了使得压测更加自动化，我们接入了Teslab自动化测试平台，可以定时启动自动化UI脚本，提升压测效率，自动化脚本是基于UiAutomator，语法非常简易，维护成本很低。
综上，第三阶段的压测策略通过客户端发起的方式，实现了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.
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!
Introduction à l'utilisation du code complet VBS
Quelles sont les performances de php8 ?
Quelles sont les performances de thinkphp ?
Comment définir l'en-tête et le pied de page dans Word
Comment créer du HTML avec Webstorm
Comment ouvrir un compte en monnaie numérique
Comment ouvrir le fichier vcf
Comment ouvrir le fichier HTML WeChat
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
