Skyforge、またはボットでの負荷テスト-サーバーの順序。 パート2

こんにちは、habrauser!



これは、 Skyforgeサーバーのテストに関する2番目の記事です。 念のため、SkyforgeはMMORPGであり、そのサーバーは数十万人のプレーヤー向けに設計されており、Javaで記述されていることを思い出してください。

ボットの役割を扱う最初のパートとは異なり、この記事ではストレステストとメトリックについて説明します。











負荷試験



Habrの読者は、ストレステストがコンプライアンスを検証するためのソフトウェアパフォーマンスインジケータの集まりであることを知っています。



このようなテストの要件は非常に単純です。「戦闘」状態のサーバーの負荷は通常の制限内であり、ユーザーエクスペリエンスが低下することはありません。 したがって、負荷テストを編成するときは、まず、どの条件が「戦闘」と見なされるかを判断する必要があります。 たとえば、私たちにとってこれは次のことを意味します:ゲームメカニックの2台のサーバー、1台のデータベースサーバーと1台のサーバーでサポートサービスが異なる5000人のプレイヤーが戯れます。 次に、どの負荷が正常と見なされるかを判断する必要があります。 サーバーのティックあたりの消費時間が20ミリ秒未満であれば、サーバーは負荷を処理できると考えています。



サービス指向のアーキテクチャがあります-これは、テスト中のサービスのトポロジが「戦闘」状態のトポロジと一致する必要があることを意味します。 また、コンテンツのボリュームは、「戦闘」に参加するボリュームに近いはずです。 一般的に、負荷テストは、実際のユーザーの代わりにボットがあるミニチュアの実稼働環境です。



試験機関



私たちのプロジェクトでのボットの使用を含むすべてのテストは、継続的な統合システムで開始されます。 テストの開始時に、ビルドエージェントはサーバーを更新して起動し、ボットを起動して設定時間待機します。その後、サーバーを停止し、結果を分析して次のテストに進みます。



リソースが限られている(ボットサイトが1つしかない)ため、何らかの方法で使用を同期する必要があります。 したがって、ボットを使用するすべてのテストは、専用のビルドエージェントで実行されます。



ナイトボットテスト



すべてのコンテンツがチェックされるメインロードテストは、夜間に8時間行われます。 なぜこの期間が選択されるのですか? 最も深刻なエラーは4.5〜6時間のターンで発生することが実験的に気付き、それらを見つけるには、このような長いテストを実行するだけです。 この間隔でFullGCポーズが発生し( この現象について )、テストの目標でもあります。 週末に56時間続く継続的なテストを実装する予定です。 しかし、今のところ、残念ながら、これらは単なる計画です。



サーバー



そして今、負荷テストの組織に関するいくつかのアドバイスを提供し、それがどのように機能するかについて話しています。 はい、私は誰かにこれらのヒントが悪名高いキャプテンのメモであるように見えることを理解していますが、誰かにはまだ有用である可能性があります。



負荷テストの最も重要な段階は、テスト用のサーバーの選択と準備です。 バトルサーバーがないため、ゲームのリリース時点でのサーバーに最も近いサーバーを選択しました。 それ以外の場合は、「バトル」と同様のサーバーを使用する必要があります。

サーバーは、「戦闘」モードで使用される場合とまったく同じように構成する必要があります。 ところで、 スレッドアフィニティテクノロジを使用する可能性を検討しています。これにより、個々のプロセッサコアを特定のスレッド(ゲームメカニクスのスレッドなど)に割り当てることができます。 また、この技術が「シュート」する場合、ストレステスト中にこの設定を有効にする必要があります。 そうしないと、テスト環境で負荷がかかっているサーバーと実際のサーバーの動作が大きく異なります。



また、最新のサーバーには「グリーン環境」または「省電力」動作モードがあることを覚えておく必要があります。 サーバーを休む時間がないため、すぐにオフにしてプロセッサをフルパフォーマンスに設定することをお勧めしますが、エコモードでのテスト中に存在しないパフォーマンスの問題を修正することはお勧めできません。



いつでもログインして、そこで何が起こっているのか、どのプロセスが実行されているのかなどを確認できるように、サイトに完全にアクセスできることが重要です。あなたとすべてのくしゃみを制御するサーバーの間に邪悪な管理者の軍隊があってはなりません。 これは2つの理由で必要です。 まず、自分でスタンドを設定し、その状態に責任を持つことにより、発生する可能性のある問題をよりよく理解できます。 次に、テストサイトで何が起きているかについての完全な情報が得られます。 これは、取得したデータの異常を分析するときに非常に役立ちます。



また、フルアクセスとは、あなたが一人でそこにいることを意味します。 負荷テストを実行する場合、同僚がサーバーで同じ作業を行っていないことを確認し、バックアップデータベースが発生しているかどうかを確認する必要があります。 あなたは、あなたが一人でそこにいることを100%確信する必要があります。



記録された統計



負荷データを分析する最も簡単で直感的な方法は、視覚化することです。 プロットにHighchartsライブラリを使用します。これは、 jqPlotを確実に置き換えました 。 いくつかの例を見てみましょう。



荷重グラフ







私は毎朝同じようなスケジュールを見ます。 負荷を追跡できます。 サーバーの負荷は、サーバーの1「ティック」のデータの処理に費やされる時間(ミリ秒)と20ミリ秒の比率に等しい値です。 グラフ上でインジケーターが複数ある場合(標準よりも大きい場合)、すべてが悪い場合、少ない場合はすべてが良好です。



メモリ使用量グラフ







これは、メモリ使用量の一般的なグラフです。 これにより、「ガベージコレクター」の作業をおおよそ評価できます。



GCスケジュール







これはおそらく、Javaサーバーにとって最も重要なグラフの1つです。 完全なガベージコレクション中にプレイヤーが一時停止に気付くことはほとんどありません。 その上で、Y軸に沿って、ガベージコレクターの1つまたは別のフェーズの期間がマークされます。



GCパフォーマンスデータを収集するために使用するキー
-詳細:gc

-XX:+ PrintGCTimeStamps

-XX:+ PrintGCDetails

-XX:+ PrintGCDateStamps

-XX:+ PrintTenuringDistribution

-XX:+ PrintGCApplicationStoppedTime

-XX:+ PrintPromotionFailure

-XX:+ PrintClassHistogramBeforeFullGC

-XX:+ PrintClassHistogramAfterFullGC

-XX:+ PrintGCApplicationConcurrentTime





セーフポイントでスケジュールを停止します







セーフポイントは、スタックトレースまたはガベージコレクションを収集する必要があるたびに停止するJava仮想マシンのポイントです。 セーフポイントの詳細については、 こちらをご覧ください 。 このグラフは、サーバーがこれらのポイントで1分間に費やすミリ秒を示しています。



データシート操作チャート







また、 Randllが委託した素晴らしい「スカーフ」もあります。Randllのデータベースに関するレポートは以前に読むことができました。 これらの「スカーフ」により、実行中のデータベース操作と量を評価できます。



さらに、高レベルのインジケーター(1人のプレイヤーとの戦闘でのMobの数)と低レベルのインジケーター(送信されたパケットの数)の両方について通知できる数十の統計もログに記録されます。 これらの統計のほとんどは、ワークロードの増加に関する調査中に確立されました。



同じ目的で、 Yourkit APIを使用して、テストの終了時にメモリダンプとロードプロファイルを自動的に削除しました。 現在は、手動モードでのみ分析されますが、このプロセスも自動化する予定です。



さくらんぼ



テストの最後に、いわゆるエラーアナライザーが起動します。 すべてのエラーを取得し、最大で100ギガバイトのエラーが夜間に実行されることもありますが、それらを棚に置きます。 最も頻繁に繰り返されるエラーとまれなエラーを比較し、それらをグループに分類します。 タイプ(エラー、警告、または情報メッセージ)でソートし、これがコンテンツエラーであるかどうかを調べます。 コンテンツエラーをQAコンテンツスペシャリストに渡し、サーバーコードのエラーを自分で調べます。







レポートには、エラーが繰り返された回数と時間間隔が示されます。 この数字は、このエラーを繰り返すことの難しさ、サーバーのコスト(サーバー上のすべてのコールスタックを収集するときに子猫が死ぬことを忘れないでください)およびバグトラッカーの優先順位を間接的に特徴づけます。

発生時間により、テスト時間ごとにエラーの分布を推定することができます。 エラーが均等に拡散する場合と、特定の時間間隔でエラーが開始および終了する場合は、まったく別の問題です。



将来、エラーをJIRAのタスクに関連付けて、エラーが最初に気づいたリビジョンを見つけることができるように、このシステムを開発する予定です。



問題



ロードナイトテストには非常にコストのかかる反復があります。 各テストの費用は1日です。 もちろん、毎晩テストに合格するようにあらゆる努力をしますが、実際には成功する頻度は低く、反復はさらに高価になります。 インフラストラクチャのノードで故障が発生すると、テストが中断する可能性があります。



おわりに



あらゆる種類の統計を使用した定期的な運動テストは、健康な睡眠開発者にとって最良のツールです。 彼のおかげで、毎朝、 完全な「緊急事態」が発生する可能性のある場所を毎朝見ているため、この種のテストなしでどのように生きることができるか想像できません。 正しい方向に進むのに役立ちます。 ご清聴ありがとうございました!



その他の資料は、Skyforge開発者のWebサイトVkontakteコミュニティで見ることができます。



レポートの作成とSkyforgeサーバーチーム全体への記事の執筆にご協力いただきありがとうございます。



All Articles