圧力試験と性能分析の方法論
パフォーマンステストの基本
パフォーマンス テストの一般的な分類
性能試験。システムの性能が設計上の期待を満たしているかどうかを検証するために使用されますが、一般にシステムにかかる圧力は比較的小さく、システムが潰れることはない、簡単な検証です。
負荷テスト。負荷圧力を継続的に適用することで、システムの最適な処理能力と最高のパフォーマンス状態を追求し、最大のパフォーマンス指数を達成します。一般に、負荷テストの結果はパフォーマンス テストの結果よりもわずかに高くなります。
安定性テスト。これは負荷テストのサブセットとして考えることができ、長時間不均一に圧力を加え、システムのすべてのインジケーターが正常かどうかを確認します。
ストレス テスト: 弊社では一般的です。一般に、システムが耐えられる最大容量を決定するためにこれをストレス テストと呼びます。ストレス テストは通常、システムが耐えられる最大点まで圧力をかけ、その後、最高の結論を導き出します。
圧力測定の種類と加圧モード
通常、ストレス テストには、単一サービス ストレス テストとフルリンク ストレス テストの 2 種類があります。
圧力を加える一般的な方法は 2 つあります。
同時モード (ユーザーの観点からユーザー モードをシミュレート)
同時実行とは、同時ユーザーの数を指します。ビジネスの観点からは、予想される同時実行量を達成するために同時オンライン ユーザーの数がシミュレートされます。スループットを計算するには、変換が必要です。ただし、シナリオによっては、シーンの期待により一致する場合もあります。
RPS モード (要求されたスループットに関してスループット モードをシミュレートします)
RPS (Requests Per Second) は、1 秒あたりのリクエスト数を指します。RPSモードは「スループットモード」で、1秒あたりに送信するリクエスト数を設定することで、サーバー側からシステムのスループット能力を直接計測することができ、コンカレントからRPSへの煩雑な変換を省略して実行することができます。ワンステップで。
同時モードと RPS モードには利点も欠点もなく、それぞれに独自の適用可能なシナリオがあります。
一般的なストレス テスト ツール
一般的に使用される圧力測定ツールは次のとおりです。
· wrk: https://github.com/wg/wrk
· ab: https://httpd.apache.org/docs/2.4/programs/ab.html
· ウェブベンチ
パフォーマンス
一般的なパフォーマンス指標
ビジネス指標: 同時実行性、スループット、応答時間
同時接続数。システムが同時に処理するリクエストの数を指し、インターネットシステムでは通常、同時にシステムにアクセスするユーザーの数を指します。
スループット (QPS の最大値): システムの処理能力を反映する、単位時間あたりにシステムによって処理されるリクエストの数を指します。通常、TPSやQPSなどの指標を使用して測定します。スループットは、平均スループット、ピーク スループット、最小スループットに分けることもできます。
応答時間: トランザクションの処理時間。これは通常、リクエストが送信されてから、サーバーが処理後に戻って、応答データを受信するまでの時間間隔を指します。一般に、平均応答時間は P95、P99 です。
応答時間とスループットは均衡点に達する必要があり、スループットが増加すると、応答時間は最初は一定の値を維持し、その後急激に増加し始め、その後スループットは増加しにくくなります。応答時間には要件があるため、スループットを追求するだけではなく、妥当な応答時間内で最大のスループットを見つける必要があります。
応答時間は成功率に基づく必要があり、失敗した場合、応答時間は無効になります。成功率は通常 100% です。
それらの間の関係は次のとおりです。
QPS (TPS) = 同時接続数 / 平均応答時間
スループットの理論値 = 同時実行数 / 平均応答時間
同時実行数 = QPS * 平均応答時間
システム リソース: CPU アイドル率、メモリ使用量、ネットワーク IO、ディスクの読み取りおよび書き込み量、ハンドル数など。
パフォーマンス カウンターは、システム負荷、オブジェクトとスレッドの数、メモリ使用量、CPU 使用量、ディスクとネットワーク I/O 使用量、その他の指標を含む、サーバーまたはオペレーティング システムのパフォーマンスのいくつかの指標データを指し ます。これらの指標はシステム監視にとって重要なパラメータであり、システム負荷と処理能力のいくつかの重要な指標を反映しており、通常、これらの指標はパフォーマンスと強く相関しています。これらの指標は高く、ボトルネックとなり、通常はパフォーマンス上の問題がある可能性があることを示します。
最適な方法はパーセンテージを使用することです
平均値を参照することは信頼できません。最も正しい統計方法は、パーセンテージ分布統計を使用することです。ベスト プラクティスはパーセンテージを使用することです。たとえば、上位パーセンタイル (TP) インジケーター、TP50 はリクエストの 50% が特定の値未満であることを意味し、TP90 はリクエストの 90% が特定の時間未満であることを意味します。
圧力測定観測インジケータ
ストレス テストの種類に関係なく、ストレス テストで観察すべき指標には通常、次のものが含まれる必要があります。
・成功率、失敗率
· システムリソース (CPU、メモリ、帯域幅、IO)
応答 時間、平均応答時間、P95/P99 応答時間。平均時間だけでなく、P95 と P99 にも注意を払う必要があります。P99 時間は、オンライン ユーザーの時間エクスペリエンスをより適切に判断できます。
・ スループット(QPS/TPS)
基本的な圧力測定データの例は次のとおりです。
厳密なストレステストレポートを生成する
システム パフォーマンスの問題を分析するときは、重要なポイントを見つける必要があります。そのためには、ストレス テスト レポートが実際に効果的で、非常に厳密で、明確である必要があります。ボトルネックを段階的に分析し、なぜボトルネックに達するのかを理解する必要があります。 、そしてそれを最適化する方法。そのため、厳密なストレステストレポートを出力することが求められます。以下にいくつかの経験を示します。
ストレス テストでは、パフォーマンスの変曲点を見つける必要があります。圧力が上昇するとすぐにボトルネックに達する場合は、最適なパフォーマンスの変曲点が見つかるまで少し戻る必要があります。システムのパフォーマンスは放物線状になっており、パフォーマンスのピークに達した後も圧力を加え続けるとパフォーマンスの低下につながるため、ストレス テストで最も重要なことは、最適なパフォーマンスの変曲点を見つけることです。したがって、加圧過程全体で徐々に加圧し、性能のピークに達した後も加圧を継続し、加圧を続けても性能が上がらずに低下した場合は変曲点に達したことになります。
パフォーマンスのボトルネックを分析し、QPS を改善できない理由を見つけるにはどうすればよいですか?
QPS は常に上昇し続けるわけではなく、ある時点を過ぎると横ばい、または低下し、パフォーマンスの変曲点が存在するため、この時点でその理由の分析を開始する必要があります。
具体的な方法としては、まず限界に達していないプロファイル状況（CPU、ブロック、IO、メモリ）を把握し、次に限界に達したばかりのものを把握し、最後に限界を超えているものを把握し、どのシステム リソースがこのような状況にあるか、外部インターフェイスがパフォーマンスの問題を引き起こしているかを分析します。
特定のコンポーネントや外部サービスが性能のボトルネックになっている場合は、コンポーネントの利用姿勢が間違っていないか、さらなる分析が必要です。接続数を処理していないのでしょうか? 特定の成分が見つかったら問題が解決したとは言えず、さらに深い検討が必要です。
スタンドアロン とクラスターがそれぞれ実現できるパフォーマンスと変曲点を理解する
単一マシンの最大 QPS はどれくらいですか?
並行拡張後の QPS はどれくらいですか? 直線的な成長ですか? (直線的に成長することは絶対にありません。あるレベルを超えると、関連するリソースにボトルネックが発生します。重要なのは、対応するボトルネック ポイントを見つけることです)
CPUを例としてシステムリソースを分析する方法
まず CPU を見てください。CPU がフルで実行されていない場合は、問題は CPU ではないことを意味するため、CPU を気にする必要はなく、IO、スワップ、メモリ、ネットワークカードなど
複数の CPU コアがある場合は、全体の CPU 使用率ではなく、各コアの CPU 使用率を観察します。
CPU がフル稼働している場合は、CPU プロファイルを取得し、どの呼び出しに時間がかかっているかを観察します。
容量見積もりを適切に行う
システムをオンラインにする前に、リソース、依存関係、展開、コンピュータ ルームの配分、ダウングレード戦略、災害復旧計画、バックアップなどのあらゆる詳細を理解するために、見積もり/評価を行い、圧力テストの検証に合格できる必要があります。プラン
大規模なシステムをオンラインにするには、キャパシティの見積もりが必須です。合理的なキャパシティの見積もりを作成することによってのみ、システムの負荷レベルに応じてシステムをより適切に設計できるからです。キャパシティ プランニングは、最小限のマシンで行う必要があります。トラフィックを増やします。計画に問題がなければ、いくつかのパフォーマンス ストレス テスト手法を使用して、それが期待を満たしているかどうかを確認する必要があります。合理的な容量計画と評価を行った後、オンラインにする前に圧力テスト システムに行くときにのみ、どの程度のストレスを与える必要があるかを知ることができます。その後、容量の見積もりは簡単ではありません。容量の評価では、次のことを考慮する必要があります。ポイント:
1. ビジネス指標を取得し、総訪問数を評価します。
製品やオペレーションについて問い合わせて、UV、PV、その他の指標を入手してください。
2. 平均訪問 QPS を評価します。
1 日あたり 86400 秒、一般的にリクエストは 1 日中に発生すると考えられます。つまり、4 ワット秒です。
合計量を合計時間で割って、1日を4w秒としてカウントします。
3. ピーク QPS を評価します。
システム容量を計画するときは、平均 QPS だけでなく、ピーク QPS も考慮する必要があります。
ビジネスカーブ図によると。
一般に、ピーク QPS は平均 QPS の 3 ～ 4 倍です。
4. ビジネスシステム全体の下で、各モジュールとサブシステムの関連指標を評価します。
5. システムを評価し、スタンドアロンの QPS を制限し、必要なマシンの数を評価します。
ストレステストとデータ分析を実行します。
6. 適切な冗長性 ストレス テストから得られた結果については、実際のオンライン プレッシャーが大きすぎて急速な拡大が引き起こされることを避けるために、実際の立ち上げ後にある程度の冗長性を確保する必要があります。
分析と要約をしっかりと行う
次のような分析と要約をうまく行ってください。
このシステムはオンラインになった後、本当に耐えられるでしょうか? ストレス テスト データに加えて、独自の見積もりも必要です。自社のシステムでは、どの部分がボトルネックとなり、オンライン化後に問題が発生する可能性がありますか? システムをオンライン化する前に、十分な準備と全体的な評価/見積もりが必要です。
システムがオンラインになった後、処理できない場合はどうすればよいですか? 流量制限スキームはありますか? ダウングレードオプションはありますか?
ユーザーが 100,000 人のシステムの現在の状況はどうなっていますか? では、この状況がユーザー数 1,000 万の場合、直線的に増加していますか? どのような考慮事項が必要ですか?
システムをオンラインにする前に、リソース、依存関係、展開、コンピュータ ルームの配分、ダウングレード戦略、災害復旧計画、バックアップなどのあらゆる詳細を理解するために、見積もり/評価を行い、圧力テストの検証に合格できる必要があります。プラン
いくつかの特定の場合の圧力測定方法
テストデータの準備
高品質のテスト データは、ユーザーの使用シナリオを真に反映できる必要があります。通常、パフォーマンス テストのテスト データとして、サンプリング、フィルタリング、感度解除を行った後、オンラインの実際のデータをデータ ソースとして選択します。ただし、実際のデータを使用してテストする前に、パフォーマンス テストに実際のデータを使用する前に、まずテスト データをオフラインでシミュレートし、少なくともシステム全体の基本的なパフォーマンス要件を確認する必要があります。
ストレージ層（データベースとキャッシュ）のストレステスト方法
ステートレスサービスの場合、同時実行能力の向上が容易であり、意識せずに容量を拡張できます。ただし、ステートフル ストレージ システムの場合、サポートできる同時実行の最大数は無限に拡張できるわけではないため、データ ストレージ レイヤーがどの程度耐えられるかを理解する必要があり、この種のストレージ クラスターの圧力テストは通常次のとおりです。
· 最初に単一のマシンでプレステストを行います
次に、 クラスタ全体の容量を分析します。クラスタが保持できる容量は、単一マシンの累積値ではないことに注意してください。通常、クラスタにマシンが追加されるたびに、おおよそ 80 で評価できます。 ％減少法。
最後に、 クラスター内のマシンが多ければ多いほど良いというわけではなく、クラスターの全体的なキャパシティは実際の状況に応じて適切な構成を達成する必要があることに注意してください。期待を満たす値まで押し下げます。