Dewu クライアントのライブブロードキャストルーム APM ストレステストの実践-Python チュートリアル-php.cn

1. 背景

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

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

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

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

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

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

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

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

3. 実施方法

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

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

#できるだけ多くの IM メッセージタイプをカバーするようにしてください
ストレステストは高度に自動化されており、手動操作のトラブルを排除します
低メンテナンスコスト

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以下に示すプロセス:

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

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

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

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

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

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

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

4.3 第 3 フェーズ

このフェーズでは、関数反復によるメッセージタイプカバレッジの問題を解決すると同時に、マニュアル操作をさらに解放します。 Teslalab 自動化に基づく介入このプラットフォームは、UI スクリプトを使用してストレステスト機能を定期的に実行し、真に自動化されたストレステスト機能を実現します。各ステップの具体的な操作については、以下で説明します。

4.3.1 メッセージタイプの対象範囲

クライアント上の各 IM メッセージタイプには、毎回、対応する IM メッセージ Java クラスがあります。 IM メッセージタイプが追加されると、それに対応するエンティティクラスが存在します。これらのクラスはすべて基本クラス BaseLiveChatMessage から継承するため、BaseLiveChatMessage にインターフェイス抽象メソッドを追加して、このメッセージタイプのモックデータを生成します。

那么我们在新加IM数据的时候，继承BaseLiveChatMessage，就需要强制覆盖这个方法，去生成自己的mock消息，非常好的解决了维护性的问题，因为不覆盖这个mock方法是无法通过编译的。

下面是警告消息和抽奖消息的Mock代码：

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

有了上面的基础，在测试工程里面加一个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
}

ログイン後にコピー

之后的压测就是控制发送频率、压测时间即可实现本地的压测，无需依赖服务端实现。

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

到此为止，基本已经解决了文章最开始的几个问题，IM消息的覆盖率和可维护性也得到了保证。

4.3.2 自动化

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

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

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

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

压测流程图：

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

五、压测效果

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

六、收益

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

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

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

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

7. 結論

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

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

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