Dewu クライアントのライブ ブロードキャスト ルーム APM ストレス テストの実践

1. 背景

ライブ ブロードキャスト業界の急速な発展に伴い、この分野に携わる企業はますます増えており、ライブ ブロードキャスト ルームの安定性とユーザー エクスペリエンスは重要な要素となっています。ライブブロードキャストプラットフォームの競争。ただし、ライブ ブロードキャスト ルームにはビデオ送信、ネットワーク通信、データ処理などの多くの複雑な技術リンクが含まれるため、ライブ ブロードキャスト ルームのパフォーマンス ストレス テストは特に重要です。クライアントのライブ ブロードキャスト ルームでのストレス テストの実践では、APM ストレス テスト テクノロジが一般的に使用されるパフォーマンス テスト方法です。アプリケーション パフォーマンスのリアルタイムの監視と診断を通じて、パフォーマンスのボトルネックを迅速に特定して解決し、ライブの安定性を向上させることができます。放送室とユーザーエクスペリエンスを改善することができます。

APM ストレス テストの重要性

1. システムの安定性の検出: APM ストレス テストは、テスターが高温環境下でのライブ ブロードキャスト ルームのパフォーマンスを評価するのに役立ちます。システムが適切に動作し、クラッシュや誤動作が発生しないことを保証するための同時実行条件と安定性。
2. ユーザー エクスペリエンスの向上: APM 値が高いということは、通常、ライブ ブロードキャスト ルームがより多くの操作をスムーズに処理できることを意味し、ユーザー エクスペリエンスが向上します。 APM 値が低いと、ライブ ブロードキャスト ルームでフリーズや遅延が発生し、ユーザー エクスペリエンスに影響を与える可能性があります。
3. システムのボトルネックの発見: APM ストレス テストは、テスターと開発者がシステムのボトルネックや問題を発見し、的を絞った最適化と改善を行うのに役立ちます。たとえば、APM ストレス テスト中にデータベースの読み取りおよび書き込みパフォーマンスの問題が発見された場合、データベースをアップグレードするか、その他の最適化措置を講じることによってシステム パフォーマンスを改善できます。
4. システム パフォーマンスの最適化: APM ストレス テストを通じて、開発者はシステム パフォーマンスの問題を特定し、対象を絞った最適化を実行できます。たとえば、負荷分散テクノロジを使用してトラフィックを分散したり、キャッシュ テクノロジを使用してデータベースの負荷を軽減したり、非同期処理を使用してシステムの同時実行機能を向上したりできます。

APM ストレス テストは、ライブ ブロードキャスト ルームの安定性を確保し、ユーザー エクスペリエンスを向上させ、システムのボトルネックを発見し、システム パフォーマンスを最適化するために非常に重要であることがわかります。

2. ライブ ブロードキャスト ルームでの一般的なストレス テスト方法

1. 負荷テスト: ライブ ブロードキャスト ルームにアクセスする多数のユーザーをシミュレートすることで、パフォーマンスをテストします。高い同時実行条件下でのライブ ブロードキャスト ルームのパフォーマンスと安定性。 JMeter や LoadRunner などのツールを使用してユーザー リクエストをシミュレートし、さまざまな負荷の下でのライブ ブロードキャスト ルームのパフォーマンスを評価できます。
2. 帯域幅テスト: ライブ ブロードキャスト ルームは、高解像度ビデオのリアルタイム送信をサポートするのに十分な帯域幅を確保する必要があるため、ライブ ブロードキャスト ルームが適切であることを確認するには、帯域幅テストが必要です。十分な帯域幅を持っています。ネットワーク速度テスト ツールを使用して、実際の帯域幅と帯域幅の安定性を評価できます。
3. パフォーマンス テスト: ライブ ブロードキャストを同時に視聴し、同時に集中砲火を送信するなど、さまざまなシナリオでユーザー アクセスをシミュレートすることにより、さまざまなシナリオでライブ ブロードキャスト ルームのパフォーマンスをテストします。 。 WebLOAD などのパフォーマンス テスト ツールを使用して同時リクエストをシミュレートし、さまざまなシナリオでライブ ブロードキャスト ルームのパフォーマンスを評価できます。
4. セキュリティ テスト: ライブ ブロードキャスト ルームではユーザー情報とプライバシーのセキュリティを確保する必要があるため、ライブ ブロードキャスト ルームにセキュリティの抜け穴がないことを確認するためにセキュリティ テストが必要です。 Burp Suite などのツールを使用して侵入テストを実施し、ライブ ブロードキャスト ルームのセキュリティを評価できます。
5. 信頼性テスト: さまざまな障害や異常な状況をシミュレートすることで、異常な状況下でのライブ ブロードキャスト ルームのパフォーマンスと回復能力をテストします。 Chaos Monkey などのツールを使用して異常な状況をシミュレートし、ライブ ブロードキャスト ルームの信頼性と回復能力を評価できます。

要約すると、負荷テスト、帯域幅テスト、パフォーマンス テスト、セキュリティ テスト、信頼性テストなどのストレス テスト方法を通じて、ライブ ブロードキャスト ルームのパフォーマンスと安定性を向上させることができます。安全性、安心感、信頼性を総合的に評価し、ユーザーのニーズと期待に応えるライブ中継ルームを実現します。

#Dewu ライブ ブロードキャスト ルームで使用される主なストレス テスト方法は、負荷テストとパフォーマンス テストです。

3. 実施方法

まず、ストレステストの目的は【生放送室をベースとしたIMパフォーマンスストレステスト】です。ストレス テストの主な目的は、クライアントのライブ ブロードキャスト ルームが長時間にわたって大量の IM メッセージを受信した場合、遅延、クラッシュ、OOM などのパフォーマンスの問題が発生するかどうかを監視することです。各リリースの前に一連のストレス テストを実行し、オフラインのライブ ブロードキャスト ルームでのパフォーマンスの問題を事前に明らかにし、パフォーマンスの問題がオンラインに持ち込まれるのを防ぎます。

特定のストレス テスト方法に関しては、次の条件を満たすことを望んでいます:

1. #できるだけ多くの IM メッセージ タイプをカバーするようにしてください
2. ストレス テストは高度に自動化されており、手動操作のトラブルを排除します
3. 低メンテナンスコスト
## ストレステストはサーバーに極力依存せず、ローカル側でメッセージストレステストを直接実装可能
#上記の要件に基づいて、ストレス テストの方法を検討しながら、ライブ ブロードキャスト ビジネス グループはおそらく次の 3 つの段階を経てきました:

4. ストレス テストの段階

4.1 章 第 1 段階

ライブ ブロードキャスト ルームのストレス テストの第 1 段階では、スクリプトを使用してユーザーがコメントやいいね! などを送信する様子をシミュレートする比較的単純な方法が採用されています。ストレス テストが必要な部屋に IM で送信します。対応する Python コードを自分で記述し、対応する IM メッセージをライブ ブロードキャスト ルームに送信する必要があります。以下は 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

Main以下に示すプロセス:

## この方法で実装された圧力テストは比較的単純です。いくつかの重要な IM メッセージをカバーできますが、いくつかの明らかな欠点もあります:

ライブ ブロードキャスト ルームの圧力テストを行うには、ルーム ID または IM を知る必要があります。この情報を取得するには、パケットをキャプチャしたり、ブロードキャスト記録を確認したりする必要があり、非常に面倒です。

1. クライアント コードが IM メッセージを追加するたびに、対応する IM 番号を追加するために Python スクリプトを手動でメンテナンスする必要があります。後のメンテナンスには特定の要件があります。メンテナンスが必要な学生Python で記述できるため、将来的には、メンテナはバージョンの反復ごとに追加される新しい IM メッセージを率先して理解し、スクリプトの IM メッセージ タイプを積極的に更新する必要があり、これによりメンテナンス コストが増加することは間違いありません。
2. 4.2 第 2 フェーズ

このフェーズでは、前のフェーズで残った問題を解決することに重点を置きます。 , これは、クライアント上で対応するブロードキャスト リスト インターフェイスを提供した後にのみ行う必要があります。問題は、ストレス テスト プロセスをより操作しやすくする方法です。ここで可視化について考えますが、マウスをクリックするだけでストレステストを実行できるのは非常に簡単ではないでしょうか?そこで、フロントエンド技術をベースに、Vue3 を使用して簡単な IM メッセージ操作ページを構築しました。このビジュアル インターフェイス上で、送信したい部屋と IM 番号を選択できます。このツールを作成する際に、IM メッセージを送信するためのロジックを強化しました。メッセージの優先順位、ルーム メッセージ、またはサイト全体のメッセージに合わせてカスタマイズでき、ちなみに、IM 模擬デバッグ用の機能もいくつかあります。

次に、これに基づいてインターフェイスを調整して、圧力テストが必要な部屋をバックエンドに伝えます。バックエンドでそれを呼び出すようにします。最初の段階のスクリプトは、対応する部屋のストレス テストを実行します。

#この方法は、ルーム ID を自分で手動で取得する手間を省き、ビジュアルな Mock プラットフォームを作成する機能です今回追加した模擬IMはストレステストとはほとんど関係がなく、スクリプトで実装するストレステスト手法と本質的には同じです。

4.3 第 3 フェーズ

このフェーズでは、関数反復によるメッセージ タイプ カバレッジの問題を解決すると同時に、マニュアル操作をさらに解放します。 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消息的覆盖率和可维护性也得到了保证。

4.3.2  自动化

在现有的基础上，为了使得压测更加自动化，我们接入了Teslab自动化测试平台，可以定时启动自动化UI脚本，提升压测效率，自动化脚本是基于UiAutomator，语法非常简易，维护成本很低。

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

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

压测流程图：

五、压测效果

六、收益

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

3 段階のストレス テストを通じて、チームはいくつかの iOS の問題を発見し、解決することに成功しました。その中で最も重要なことは、ストレステストが20分以上続いた場合、CPUが異常に高くなり、インターフェイスがスタックしたことです。調査の結果、この問題はメッセージがビジネス層に 1 つずつ配信されるため、CPU が過剰に消費され、UI が頻繁に更新される (1 秒あたり最大数十回) ことが判明しました。この問題に対処するために、チームは 2 つの解決策を採用しました: 1 つは、メッセージを 1 つずつ配信するのではなく、タイマーを通じてメッセージ グループをビジネス層に配信することであり、もう 1 つは、スレッドの切り替えが 1 つだけになるようにタイマー内でスレッドの切り替えを実行することです。期間内です。

さらに、チームはストレス テスト中にメモリの継続的な増加によって引き起こされる OOM 状況も発見しました。その理由は、一部の IM にはアニメーションの実行時間があり、一度しか実行されないためです。同時実行の場合は、継続的に蓄積され、メモリ オーバーフローが発生します。この問題を解決するために、チームはメモリ オーバーフローを回避するアニメーション実行の最適化ソリューションを採用しました。

さらに、kylin コンポーネントを通じて、チームはいくつかのメモリ リークの問題も発見し、それらを時間内に解決して、ライブ ブロードキャスト アプリケーションの安定性と信頼性を確保しました。つまり、3 段階のストレス テストを通じて、チームは複数の問題の発見と解決に成功しました。これにより、アプリケーションのパフォーマンスと安定性が向上しただけでなく、チームのテクノロジーの蓄積と開発に有益な経験とインスピレーションがもたらされました。

7. 結論

パフォーマンス ストレス テストは確かにライブ ブロードキャスト ルームの安定的かつ効率的な運営を確保するための重要な手段ですが、これを目的とみなすことはできません。コード開発のポイント。優れたコードはチーム全体で保守可能である必要があり、コードの読みやすさ、保守性、拡張性も同様に重要です。開発とメンテナンスのプロセス中にコードの品質とチームのコラボレーションに継続的に重点を置くことによってのみ、ライブ ブロードキャスト ルームがユーザーに高品質のサービスを提供し続けることができます。

ライブ ブロードキャスト ルームでパフォーマンス ストレス テストを実施するときは、コードの可読性と保守性にも注意を払う必要があります。コードの信頼性とスケーラビリティを確保するために、コードの品質を監視および制御するための厳格なコード レビュー メカニズムを確立する必要があります。同時に、チームのコラボレーションに重点を置き、チームメンバーが共同でライブブロードキャストルームを維持し、より良いユーザーエクスペリエンスを提供できるように、チーム内にコミュニケーションと協力のメカニズムを確立します。

以上がDewu クライアントのライブ ブロードキャスト ルーム APM ストレス テストの実践の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。