ライブ ブロードキャスト業界の急速な発展に伴い、この分野に携わる企業はますます増えており、ライブ ブロードキャスト ルームの安定性とユーザー エクスペリエンスは重要な要素となっています。ライブブロードキャストプラットフォームの競争。ただし、ライブ ブロードキャスト ルームにはビデオ送信、ネットワーク通信、データ処理などの多くの複雑な技術リンクが含まれるため、ライブ ブロードキャスト ルームのパフォーマンス ストレス テストは特に重要です。クライアントのライブ ブロードキャスト ルームでのストレス テストの実践では、APM ストレス テスト テクノロジが一般的に使用されるパフォーマンス テスト方法です。アプリケーション パフォーマンスのリアルタイムの監視と診断を通じて、パフォーマンスのボトルネックを迅速に特定して解決し、ライブの安定性を向上させることができます。放送室とユーザーエクスペリエンスを改善することができます。
APM ストレス テストは、ライブ ブロードキャスト ルームの安定性を確保し、ユーザー エクスペリエンスを向上させ、システムのボトルネックを発見し、システム パフォーマンスを最適化するために非常に重要であることがわかります。
要約すると、負荷テスト、帯域幅テスト、パフォーマンス テスト、セキュリティ テスト、信頼性テストなどのストレス テスト方法を通じて、ライブ ブロードキャスト ルームのパフォーマンスと安定性を向上させることができます。安全性、安心感、信頼性を総合的に評価し、ユーザーのニーズと期待に応えるライブ中継ルームを実現します。
#Dewu ライブ ブロードキャスト ルームで使用される主なストレス テスト方法は、負荷テストとパフォーマンス テストです。
まず、ストレステストの目的は【生放送室をベースとしたIMパフォーマンスストレステスト】です。ストレス テストの主な目的は、クライアントのライブ ブロードキャスト ルームが長時間にわたって大量の IM メッセージを受信した場合、遅延、クラッシュ、OOM などのパフォーマンスの問題が発生するかどうかを監視することです。各リリースの前に一連のストレス テストを実行し、オフラインのライブ ブロードキャスト ルームでのパフォーマンスの問題を事前に明らかにし、パフォーマンスの問題がオンラインに持ち込まれるのを防ぎます。
特定のストレス テスト方法に関しては、次の条件を満たすことを望んでいます:
4. ストレス テストの段階
4.1 章 第 1 段階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
Main以下に示すプロセス:
## この方法で実装された圧力テストは比較的単純です。いくつかの重要な IM メッセージをカバーできますが、いくつかの明らかな欠点もあります:
ライブ ブロードキャスト ルームの圧力テストを行うには、ルーム ID または IM を知る必要があります。この情報を取得するには、パケットをキャプチャしたり、ブロードキャスト記録を確認したりする必要があり、非常に面倒です。
次に、これに基づいてインターフェイスを調整して、圧力テストが必要な部屋をバックエンドに伝えます。バックエンドでそれを呼び出すようにします。最初の段階のスクリプトは、対応する部屋のストレス テストを実行します。
#この方法は、ルーム ID を自分で手動で取得する手間を省き、ビジュアルな Mock プラットフォームを作成する機能です今回追加した模擬IMはストレステストとはほとんど関係がなく、スクリプトで実装するストレステスト手法と本質的には同じです。 
このフェーズでは、関数反復によるメッセージ タイプ カバレッジの問題を解決すると同時に、マニュアル操作をさらに解放します。 Teslalab 自動化に基づく介入 このプラットフォームは、UI スクリプトを使用してストレス テスト機能を定期的に実行し、真に自動化されたストレス テスト機能を実現します。各ステップの具体的な操作については、以下で説明します。
4.3.1 メッセージ タイプの対象範囲クライアント上の各 IM メッセージ タイプには、毎回、対応する IM メッセージ Java クラスがあります。 IM メッセージ タイプが追加されると、それに対応するエンティティ クラスが存在します。これらのクラスはすべて基本クラス BaseLiveChatMessage から継承するため、BaseLiveChatMessage にインターフェイス抽象メソッドを追加して、このメッセージ タイプのモック データを生成します。
那么我们在新加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压测使用方式方便、支持多设备压测和压测指标有记录的目标。同时，我们还需要在实际实施过程中不断优化和改进，以进一步提高压测效率和结果的可靠性。
压测流程图：
压测只是一个手段，最重要的是发现问题，解决问题，通过三个阶段的压测也发现了不少问题。
3 段階のストレス テストを通じて、チームはいくつかの iOS の問題を発見し、解決することに成功しました。その中で最も重要なことは、ストレステストが20分以上続いた場合、CPUが異常に高くなり、インターフェイスがスタックしたことです。調査の結果、この問題はメッセージがビジネス層に 1 つずつ配信されるため、CPU が過剰に消費され、UI が頻繁に更新される (1 秒あたり最大数十回) ことが判明しました。この問題に対処するために、チームは 2 つの解決策を採用しました: 1 つは、メッセージを 1 つずつ配信するのではなく、タイマーを通じてメッセージ グループをビジネス層に配信することであり、もう 1 つは、スレッドの切り替えが 1 つだけになるようにタイマー内でスレッドの切り替えを実行することです。期間内です。
さらに、チームはストレス テスト中にメモリの継続的な増加によって引き起こされる OOM 状況も発見しました。その理由は、一部の IM にはアニメーションの実行時間があり、一度しか実行されないためです。同時実行の場合は、継続的に蓄積され、メモリ オーバーフローが発生します。この問題を解決するために、チームはメモリ オーバーフローを回避するアニメーション実行の最適化ソリューションを採用しました。
さらに、kylin コンポーネントを通じて、チームはいくつかのメモリ リークの問題も発見し、それらを時間内に解決して、ライブ ブロードキャスト アプリケーションの安定性と信頼性を確保しました。つまり、3 段階のストレス テストを通じて、チームは複数の問題の発見と解決に成功しました。これにより、アプリケーションのパフォーマンスと安定性が向上しただけでなく、チームのテクノロジーの蓄積と開発に有益な経験とインスピレーションがもたらされました。
パフォーマンス ストレス テストは確かにライブ ブロードキャスト ルームの安定的かつ効率的な運営を確保するための重要な手段ですが、これを目的とみなすことはできません。コード開発のポイント。優れたコードはチーム全体で保守可能である必要があり、コードの読みやすさ、保守性、拡張性も同様に重要です。開発とメンテナンスのプロセス中にコードの品質とチームのコラボレーションに継続的に重点を置くことによってのみ、ライブ ブロードキャスト ルームがユーザーに高品質のサービスを提供し続けることができます。
ライブ ブロードキャスト ルームでパフォーマンス ストレス テストを実施するときは、コードの可読性と保守性にも注意を払う必要があります。コードの信頼性とスケーラビリティを確保するために、コードの品質を監視および制御するための厳格なコード レビュー メカニズムを確立する必要があります。同時に、チームのコラボレーションに重点を置き、チームメンバーが共同でライブブロードキャストルームを維持し、より良いユーザーエクスペリエンスを提供できるように、チーム内にコミュニケーションと協力のメカニズムを確立します。
以上がDewu クライアントのライブ ブロードキャスト ルーム APM ストレス テストの実践の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
