周知のとおり、アプリケーションの優れたパフォーマンスは優れたユーザー エクスペリエンスの強固な基盤であり、サーバーの応答が遅い、フリーズ、クラッシュする製品は、どんなに美しくデザインされていてもユーザーの心を掴むことはできません。
2017 年 2 月 28 日、百度はユーザーにちょっとした冗談を言いました。その日の 20:54 から 21:24 まで、百度の検索は 30 分間停止しました。多くのネチズンは、この 30 分が百度にとって最も意味のある 30 分になったと冗談を言いましたが、その後の百度の広報記事では、「皆様からの数億件の検索リクエストを見逃している」と言及されていたことがわかりますが、大きなインパクトでした。
奇しくも、本日のヘッドラインも今年1月にダウンタイムが発生し、システムが30分以上応答しなくなり、ヘッドラインの編集背景にアクセスできなくなるなど、ユーザーに多大なご迷惑をおかけし、ユーザー数も増加傾向にありました。つまり、影響は広範囲に及び、ユーザーの評判に影響を与えるだけでなく、製品の収益にも影響を与えることになります。
製品の月収を分ごとに分割すると、30 分、60 分、さらには 12 時間、24 時間のサービスダウンタイムに加え、その結果生じるユーザー損失とブランド損失を加えた具体的な損失額を計算できます。影響。
有名な海外のゲームが発売当初 iOS 無料リストで 2 位になったとき、プレイヤーの流入に対処する準備が整っていなかったためにサーバーが停止し、ダウンし、フラッシュバックがプレイヤーを失望させました。ダウンロードランキングは一時 475 位まで下がり、この状況を救うにはサーバーの最適化に 2 か月かかりました。
このような例は数多くあり、重いゲームや重い製品が登場するにつれて、サーバーのパフォーマンスの最適化にますます注意を払う製品が増えています。この記事では、Tencent のゲームと製品のサーバー ストレス テストを実行した Tencent WeTest チームの経験に基づいたいくつかの方法とアイデアを共有します。
サーバーのパフォーマンスの中心的な指標は何ですか
サーバーのストレス テストには多くの指標があります。誰もが理解しやすいように、実際の例を次に示します。
昼食のためにハイディラオに行きます。レストラン「Haidilao」はテスト中のシステムとみなすことができます。食事に行くときは、テスト対象のシステムへのリクエストを開始することになり、システムに一定の負荷がかかります。人数が増えれば増えるほどお店は忙しくなり、いわばお店の負担は大きくなります。
注文を開始します。この時、隣のテーブルの人も注文を始めます。次に、2 人がシステムに対して同時にリクエストを行います。同時に、他のテーブルのいくつかは食事をしており、いくつかは食べ物を待っています。これらはすべて同時トランザクションです。完全な食事トランザクションは、注文、発注、提供、支払いの 4 つのステップを含むものとして定義できます。C/S システムの場合、接続の確立、要求の送信、応答の受信、切断に対応できます。
レストランのビジネスの品質に影響を与える重要な要素は、料理を提供する速度です。サービス提供速度は次の 2 つの側面に反映されます。
1. 顧客の要求に対する時間のかかる処理、注文から料理の提供までの待ち時間、これを応答時間と呼びます。
2. レストランが同時に複数の顧客にサービスを提供する頻度。これをスループットと呼びます。
どれだけの客が来るかはレストラン自体がコントロールすることはできませんが、料理を提供するスピードとレストランの座席数によって客の流れが制限されます。乗客の数にはピークがあり、そのピークを超えると、客は席を待つことになるか、料理の提供速度が非常に遅くなり、ゲストが耐えられなくなります。キャパシティテストとは、ツールを使用して十分な客数をシミュレートし、レストランに一定の負荷を与えるような客の流れを見つけることを目的としており、この時点でレストランは最も多くの客を受け入れ、最短の待ち時間を保証できます。さらに、リソースの最適な利用と効率を達成するために、レストランの人員配置とテーブル設定を最適化することも可能です。
客の流れは来店客の数にも関係しますし、お店の受け入れ能力にも関係します。一方的に食べに来る客が増えればクレームの可能性も高まり、料理を間違える可能性も高まります。
業績指標は数多くあり、すべてを見ることは不可能ですが、中核となる指標は何でしょうか?
1. 90% の応答時間
これは、すべてのユーザーの応答時間が小さいものから大きいものまで分類されることを意味し、90% の応答時間はシステムの能力を評価するために使用される重要な指標の 1 つです。
2. TPS パフォーマンス、サーバーのサービス能力に注意してください。
システムによって 1 秒あたりに処理されたトランザクション (成功、失敗、停止) の数。これにより、任意の瞬間におけるシステムの一時的なトランザクション負荷を判断できます。
3. サポートされるオンライン ユーザーの最大数。
サイトに同時にログインする人の最大数、またはサーバーが同時に受信するダウンロードの最大数を指します。
4. サーバー自体のストレス テスト プロセスの合計 CPU、メモリなどの変更。
CPU 使用率とは、非システムアイドルプロセスの CPU 実行時間/合計 CPU 実行時間を指します。メモリ使用量は、このプロセスによって消費されるメモリを指します。
5. 取引成功率
トランザクション成功率 = 正常に処理されたトランザクション / すべてのトランザクション * 100%。これは、サーバー処理トランザクションの成功確率を検出するための重要な指標です。
市場ではどのようなサーバー ストレス テスト方法が利用できますか?
ユーザーがサーバーのコアデータをより迅速に取得できるようにするために、さまざまな圧力テスト方法が市場で開発されていますが、さまざまな問題もあります。
1. ライブネットワークデータの推定
このモデルは、ストレステストプロセスのデータの一部に基づいて、将来の大量のユーザーアクセスの状況を予測します。
問題があります。これは単純なサーバーの調整にのみ適しており、複雑なサーバー データはあまり正確ではありません。
2. 実人圧力テスト
一定数の実際のユーザーをゲームに招待することで、サーバー上でテスト効果を得ることができます。
既存の問題: 明らかになっているパフォーマンスの問題は限られており、ベータ テスターの数は通常少なすぎます。数百または数千のユーザーがプレイしていますが、同時実行性はサーバーのパフォーマンスの問題を明らかにするのに十分ではありません。また、サーバーのパフォーマンスの問題を明らかにするのには適していません。まったく同じ動作を繰り返すと、サーバーの回帰が困難になります。
3. インターフェーステスト
いくつかの代表的な機能を選択し、大きなことから小さなことまで見てサーバー全体のパフォーマンスを評価します。問題があります。サーバー全体のインターフェイスを横断することは不可能であり、いくつかの小さな問題を回避することは困難です。
4. 録音再生
データパケットをキャプチャすることでゲーム中のプロトコルが取得され、キャプチャされたプロトコルがサーバーに再送信され、ツールによってプロトコルレベルが増幅されてパフォーマンステストの目的が達成されます。
問題があります。複雑なプロトコルの相互作用に直面して、データ パケットを単純に増幅するだけでは十分な圧力を生成できません。
5. ロボットシミュレーション
実際のプレーヤーのユーザー動作を高度に復元し、同時実行性の高いシナリオをシミュレートすることにより、テストの効果は、多くの人が同時にゲームをプレイする場合と同様になります。
これらの方法にはそれぞれ長所と短所があり、テンセントでは一般にストレス テストに「ロボット シミュレーション」方法を使用しますが、「ロボット シミュレーション」ストレス テスト方法は十分なテスト時間と多大な労力を必要とします。このため、テンセントはより一般的なテスト プロセスは、ストレス テストの効率を向上させるために使用されます。
Tencent の内部サーバーのパフォーマンスのテスト プロセスの紹介
Tencent の社内ゲームおよび製品の使用要件に従って、Tencent WeTest チームはまず、http および https プロトコルを使用するページの一般的なストレス テスト プロセスを整理しました。
1. ログイン、情報リストの取得などのストレス テストのシナリオを決定します。
テスターの最初のステップはテスト計画の確認であり、主に実際の業務に関わるシナリオとそのシナリオにおけるユーザーの動作を事前にシミュレーションするためのもので、通常は以下の点を確認する必要があります。
1) ユーザーのログイン状態を確認し、ユーザーのログイン状態が継続的に変化するかどうかを確認します。
2) ユーザーログイン後のアクセスパス間のコンテキスト関係
3) アクセスパス間のパラメータ転送関係
2. テスターがテスト ケースを作成する
テストケースの作成とは、テストする人数の確認、人数を増やすロジック、押す必要のある特定のインターフェイス、インターフェイス間のパラメータの受け渡しなど、上記のシミュレーションシナリオを具体化するプロセスです。
3. テスト用にロボットを起動し、徐々にロボットの数を増やします
テスト計画を確認した後、このステップは実行プロセスであり、テスト計画で推定されたストレスを受ける人の数に従って、ストレスを受ける人の数を徐々に増やします。
4. データとトランザクション処理を記録および分析し、サーバー負荷の変化とサーバーの現在の処理能力を確認します。
前のステップではロボットを徐々に増やす必要があると述べましたが、なぜロボットを徐々に増やす必要があるのでしょうか。サーバーの同時実行数を増やす過程では、上記のサーバーのコア データを継続的に監視し、サーバーの処理能力の限界に常に挑戦し、サーバーの処理能力の限界を直接超える過度に高い同時実行数の使用を避ける必要があるため、パフォーマンス最適化の目的を達成できません。一般に、ロボットの数を増やす過程で、CPU が急激にいっぱいになり、応答時間の瞬間的な増加がサーバーのボトルネックになることがあります。したがって、ストレス テスターは、問題を特定するために、ストレス テストの上昇中にサーバーのステータスの変化をリアルタイムで監視する必要があります。
5. 構成を調整し、テストを繰り返し、サーバーの収容能力と潜在的なパフォーマンスのボトルネックを推定します。
基本的なテストの問題を発見した後、テスターは継続的なデバッグを通じて問題を特定し、最終的なテストの目的が達成されるまでストレス テストを再開する必要があります。
このテストプロセスに従って、テンセントは一部のストレステスト製品に必要な特性を社内で要約しました。
1. 使いやすい
製品のビジネス シナリオは変更可能ですが、優れたストレス テスト製品では、このシナリオの構成プロセスが使いやすくなる必要があります。ユーザーは、テストする必要がある URL を入力するだけで各インターフェイスをテストできます。ほとんどのテスト構成は、提供することをお勧めします。デフォルト値では、ユーザーは機能をよく理解した後、これらのパラメータを自由に設定できます。
2.充実の先進機能
シンプルで使いやすいだけでなく、URL を入力するだけでユーザー定義変数をサポートしたり、ファイルから変数を読み取ったり、変数値を取得したりできる高度な機能もユーザーに提供する必要があります。他の URL の戻り値から取得することで、実際のシーンをより現実的にシミュレートし、単一のリクエスト変数を回避できます。
3. 圧力測定用の分散プレスを提供する
単一のマシンには限界があるため、ストレス テスト製品では分散ストレス テスト フレームワークを使用して、ユーザーが構成したロボットの数に応じて複数のストレス テスト マシンを動的に割り当てることができ、圧力の上限を大幅に高めることができます。
4. 詳細なテストデータの統計
圧力テストマスターは、テストプロセス中に、オンラインユーザー数の変化、TPSの変化、応答時間、送受信パケットトラフィック、サーバーのCPUメモリステータス、印刷機のハードウェア負荷、テスト結果の統計などを含む複数のデータを記録します。これにより、サーバーの容量とボトルネックを迅速に特定できます。
これらの要件に基づいて、Tencent WeTest チームは、サーバーのストレス テストに焦点を当てた製品「ストレス テスト マスター」を開発しました。これにより、ストレス テストの構成プロセスが簡素化されます。ユーザーはオンラインで展開し、オンラインでデバッグし、オンラインでレポートを表示できるため、ユーザーは最も効率的な「圧力測定の達人」。
テストケース: 「NOW Live」イベントシーンのリアルシミュレーション
Tencent NOW ライブ ブロードキャストは、現在非常に急速に開発されているライブ ブロードキャスト アプリケーションであり、オンライン イベント中に、イベントのすべてのインターフェイスでストレス テストを実施し、事前に問題を明らかにして解決し、イベントをスムーズに実施する必要があります。イベント。この目的を達成するために、NOW ライブ ブロードキャスト チームは、「ストレス テスト マスター」を使用して、イベントに関する完全なシナリオ テストを実施することにしました。
「Pressure Test Master」には「ページテスト」「URLテスト」「アドバンストモード」の3つの機能が含まれています。
「ページテスト」はHTTPおよびHTTPSプロトコルに適用可能で、Web、H5などのページのストレステストを実行でき、主にページ上の静的リソースの圧力データをテストし、公式Webサイト公開時のWebサイトの安定性の向上に役立ちます。大規模な運用活動を促進します。
「URL テスト」では、ユーザーの同時成長フォーム、異なる URL のコンテキスト パラメーター構成、およびサーバー監視を設定して、最大 16 のユーザー シナリオを同時に実現し、より多くのシナリオ構成を実現できます。
「アドバンスト モード」は、HTTPS およびカスタム プロトコルなどを含むその他のプロトコルに適用されます。ゲームや製品プロトコルのストレス テストをサポートしており、ユーザーはコード構成を通じて独自のニーズに応じてプロトコル ストレス テストを有効にすることができます。
テストプロセスでは、まず NOW ライブブロードキャストチームがテストのアイデアを整理しましたが、一方で、単一インターフェイスのストレステストを通じて、コアモジュールの問題が事前に明らかになり、説得力がありました。
テスト中、「NOW Live」は「Pressure Test Master」のURLテスト機能を利用し、「メッセージ送信」「いいね！」「アナウンスプル」「登録」「ルーム情報読み取り」「入室」をテストした。 Behavior は、単一インターフェイスの圧力テストを実施し、圧力テストの初期人数、各段階での増加人数、および最大人数を設定することにより、インターフェイスの圧力状況を設計します (下図を参照)。
「耐圧テストマスター」のURLテストの「人数設定」
また、「NOW Live」では、ユーザーのアクセス行動に応じて、「登録室→情報室入室」（下図参照）、GETによるユーザーの「ログイン状態」の読み取りなどのマルチシナリオストレステストを実施しました。機能インターフェイスは、実際の QQ ユーザーをシミュレートするためにさまざまな動作ロジックを持つロボットをランダムに生成し、次に POST リクエストを通じて特定のビジネス動作を順番に実行し、最後に URL テストの「コンテキスト設定」を通じてさまざまな機能インターフェイスを選択して呼び出します。関数間の違いを見つけるために、論理的に問題が発生します。
「圧力テストマスター」URLテストの「コンテキスト設定」
数日間の集中的なテストの後、NOW ライブ ブロードキャスト アクティビティの各シーンのデータは大幅に改善され、その中で「ユーザーが部屋に入る」シーンの応答時間はほぼ半分に短縮され、「ユーザーが部屋に入る」シーンの TPS は大幅に短縮されました。 「メッセージを送る」「いいね！」が4倍に向上し、安定した活動展開を保証します。
ゲームであろうと製品であろうと、テンセントは数え切れないほどのサーバー テストを経験し、これらのテストに直面して、テンセントは徐々に一般的なアプリケーション パフォーマンス管理ソリューションのセットをまとめ、ゲームがオンラインになる前にユーザーが実際のビジネス シナリオとユーザー行動を使用できるようにしました。ストレス テストを実施して、サーバー側のパフォーマンスのボトルネックを発見し、ターゲットを絞ったパフォーマンス チューニングを実行します。上記の内容は、テンセント製品の無数のストレステストに基づいて要約された経験の一部でもあり、テンセント WeTest チームは、「ストレス テスト マスター」などの製品を使用して、サーバーのストレス テスト プロセスを継続的に簡素化し、ストレス テスト担当者の作業効率を向上させたいと考えています。
実際の事例
光学理論は役に立たず、それに従って学ぶ必要があり、学んだことを実践に応用できるように自分でやる必要がありますが、このとき、いくつかの実戦事例から学ぶことができます。
参考になった場合は、いいね、収集をして作者の励みとさせていただきます。次回からすぐに見つけられるのも便利です。
理解できない場合は、下の小さなカードを参照してください。ブロガーは、同じ考えを持つテスターと一緒に学び、進歩することも望んでいます。
適切な年齢で、適切なポジションを選択し、自分の長所を最大限に発揮するように努めてください。
私の自動テスト開発の道は、計画と要約が好きなので、途中の各段階の計画と切り離せないものです。
ビデオチュートリアルをテストして開発し、ノートを学習し、ポータルを受け取りましょう! ！！