前の部分の要約
- Skyforgeは、サイエンスファンタジーの世界で行われるMMORPGです。 ゲームの世界はすべての地域で同じです。 つまり、ロシアのすべてのプレイヤーと旧ソ連の他の国々が一緒にタスクを完了し、世界を救い、神になることができます。 サーバーによる区分はありません。
- SkyforgeサーバーはJavaで記述されており、アーキテクチャについては、対応するrandllの 投稿で詳細に説明されています。
- データベース-PostgreSQL +分散トランザクション。
- ボットはC ++で記述されたプログラムで、実際のプレーヤーの動作をシミュレートします。 ボットは、正直なゲームクライアントと同じプロトコルで動作し、同じコマンドセットを使用します。一般に、サーバーの観点からは、通常のクライアントとはわずかに異なります。
- 負荷テスト-サーバーが負荷を保持できるかどうかに関する情報を取得することを目的とした一連の手段。 さまざまな種類の負荷テストを1日に数回実行します。 平均テストは40分続きますが、正味のテスト時間は60〜80分です。
より多くのストレステスト
かなり長い間、「クライアント」負荷テストが、実行した唯一の負荷テストのままでした。 しかし、時間が経過し、野心が高まり、ニーズが変化し、クライアントボットを使用して与えるよりも負荷をテストする必要があるタスクが現れました。 この制限の主な原因は、クライアントボットが非常に多くの「サードパーティ」の事柄に関与していたことです。最終的に、決定を下し、いくつかの条件を正直にチェックし、プレイしました。 そのため、Javaで記述されたサーバーボットが登場し始めました。ロジックがなく、熱を与えているだけです。 現在、このような「ボット」には3つのタイプがあります。- データベース-クローズドテストからの実際のプレーヤーのプロファイルとランダムデータをソースプロファイルとして使用して、盲目的にデータベース操作を送信します。
- チャットボット-チャットサービスに対してのみ、データベースボットと同じ操作を行います。
- 統計ジェネレーター-考え方は以前の2つのケースとまったく同じですが、統計サブシステムに関するものです。
これらのテストは、ストレスの多いテストとして非常によく表れていますが、それ以上のことは期待していませんでした。 彼らは単純な「機能しない」以上のエラーを見つけることができません。 しかし、結果の再現性が非常に優れている点で異なり、開発とサポートの点ではるかに安価です。 腺でも節約について話すと、次のようになります。
- クライアントボットによる10k CCUのテストには、7（ロードオブジェクト）+ 10（ボット）=合計17台のサーバーが必要です。
- 50k CCUデータベースサーバーをテストする場合：4 + 2 = 6サーバー。
- 100k CCU chatika：4 + 2 = 6サーバー;
- 100k CCU統計システム：2 + 1 = 3サーバー。
これは主に、戦闘構成から遠ざかるほど余裕があるという事実によるものです。 たとえば、統計システムのテストでは、原則として、ゲーム自体に関連する単一のスペアパーツはなく、データ自体を処理するアプリケーションのみがあります。 チャットルームまたはデータベースのテストでは、ゲームメカニクスを意図的にロードせず、ゲームレルムを最小起動構成に保ち、ロードオブジェクトのみが完全な戦闘モードになります。 また、テストに参加するサブシステムが少ないほど、テストの安定性が高くなることにも注意してください。
クライアントボット
しかし、サーバーボットがどれほど美しくても、クライアントボットを拒否するつもりはありません。 それらの利点ははるかに大きく、負荷プロファイルは可能な限り実際のものに近いためです。 そのため、過去1年間で大幅に改善されました。 今、彼らはほぼ完全にゲームのコンテンツの大部分を渡すことができます。 同時に、最小限のサポートが必要です。 このように見えます：ボットはマップに表示され、そのクエストトラッカーを見て、そこにポイントAに実行する指示が表示され、実行されます。 ボットは外の世界と対話するように訓練されているという事実により、ポイントAで誰かと話をしたり、何かと対話したり、すべての攻撃者を殺そうとします。 ほぼその自転車のように：それは私を食べることができますか？ そして私は彼？ しかし、これと交尾できますか？ 私と一緒ですか？ :)また、メモリ消費量が大幅に減少したため、ゲームクライアント自体の最適化はボットを通過しませんでした。 また、1台の物理マシンから2倍のボットを起動できるようになりました（1kではなく2k）。
現在、次のスキームに従ってクライアントテストを実施しています：全員がゲームの開始に合格し（負荷の点で私たちにとって最も重要な瞬間）、全員が何らかの形でプレイします（さまざまなアクティビティに参加しているプレイヤーのプロファイルが頭から取得されます）、全員が特定のマップでプレイします。 これにより、負荷の点で不良なカードを見つけ、それらの作成プロセスにすばやく介入できます。 静かな時間にどのような負荷プロファイルがあるかを見て、ゲームの開始時にすべてが正常であることを確認してください。
これらのツールがなければ、ストレステストは10倍鈍くなるでしょう。
これはおそらく記事の中で最も有用な部分です。 負荷テストを実施する場合、サーバーが負荷を保持しているかどうかを知るだけでは不十分です。 最も重要なことは、何が間違っているのかを正確に理解する能力です。 Java Mission Controlとその機能Flight Recorderは、ここで非常に貴重な貢献をしています。 残念ながら、戦闘サーバー上のこのオプションは非常に高価（$）なので、テストでのみ使用します。 次のようになります。-XX:+UnlockCommercialFeatures # JMC
-XX:+FlightRecorder #
-XX:StartFlightRecording=name=skyforge,filename=skyforge.jfr,delay=40m,duration=10m,settings=jmc.jfc
詳細については、 OracleのWebサイトをご覧ください 。
その後、JMCを使用してこのダンプを開くことができます。 ダンプは、すべての必要な情報を提供します。割り当ての統計、プロセッサ時間を消費した人、サーバーのCPU負荷全体に対するプロセスの寄与などです。 JMCは優れていますが、軍事サーバーでは使用できないため、祖父のメソッド-GCログを使用します。GCログからは、gcで1分あたりどれだけの時間を費やしたか、同じ期間のアプリケーションの合計停止時間、どのオブジェクトがFullGCの前にあり、どのオブジェクトが後にあるのか：
-XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintClassHistogramBeforeFullGC -XX:+PrintClassHistogramAfterFullGC -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime -XX:+PrintPromotionFailure -Xloggc:memory/gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=memory/heap.dump
グラフの例：
前と後の統計の例：
念のため、リモートデバッグのオプションを使用してすべてのサーバーを起動します。 これにより、何か問題が発生した場合に多くの時間を節約でき、ログから問題の正確な原因が不明です。
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=51003
独自の統計
既製のプロファイリングツールを使用することに加えて、独自のツールを積極的に開発しました。 そのため、たとえば、プレイヤーが召喚するすべての呪文を記録し、それに費やされたプロセッサー時間を測定します。 これにより、最初に最適化する必要がある特定の能力とメカニズムについて決定を下すことができます。
データベースの操作についても同様の統計を実施します。どの操作が実行されたかだけではありません。
しかし、それらの実行の時間：
トラフィックを最適化するには、独自の決定も行う必要があります。 したがって、量と量の両方を考慮して、送信されたメッセージを正確に測定します。
テストレポート作成時の最適化
テストの数とグラフの数の増加に伴い、1つのプロセスでテストを準備、実施、分析することは容認できない贅沢であることが明らかになりました。 この点で、テスト結果の直接分析とレポートの作成は、CIシステムとはまったく関係のない別のサービスに提出されました。 これにより、追加のテストを実行する時間が解放されました。また、レポート作成用の別のサービスの割り当ては、負荷テスト、バトルサーバー、または他のテストベンチからのデータを表示するための単一のエントリポイントの出現に貢献しました。
熊手
テスト中は、これらのテストが実施されるインフラストラクチャを制御することが非常に重要です。 以前の記事で、電力を節約するためにプロセスのクロック速度を人為的に低下させたときにCPU周波数ガバナーに問題があることを既に述べました。 だから、私たちは再びそれに落ちました。 現在、これらのフラグの検証をサーバーに埋め込む方法を考えています。 また、たとえばデータベースサービスでは、データベースに同期レプリカが構成されていることを確認する機能を追加しました。 突然の「シャットダウン」により、パフォーマンスが著しく向上するためです。 一般に、環境チェックをサービス自体に直接追加することをお勧めします。 これにより、サーバーが設計された正確な環境で運用およびテストされます。結論
まず、ストレステストは、ソフトウェアの品質を改善する他の手段と同様に、常に使用する場合にのみ最大のメリットをもたらすことに注意してください。 はい、テストのサポートには手間がかかりますが、それだけの価値はあります。 火災モードよりも穏やかな環境でこれらの努力を費やすことをお勧めします。次に、大規模で複雑な分散システムがある場合は、統合負荷テストに加えて、個々のコンポーネントで負荷テストを実行することをお勧めします。 これは一般的に安価であり、そのようなテストはより柔軟にできます。
そして、第三に、負荷テストは、実装のために作成されたストラップのかなりの部分が戦闘状態でも非常にうまく機能するという点でも有用です。
それだけです いつものように、私はコメントの質問に喜んで答えます。