乾物共有、大工場の内圧測定方式の設計

01 圧力試験を行う理由

1. ストレステストとは？

試験中の物体に継続的に圧力を加えて、応力下でのシステムの性能を試験します。

2. ストレステストの目的は何ですか?

合理的なコミットメント値または容量警告を与えるために、システムの限界性能指数を取得するためにテストします。

システムのパフォーマンスのボトルネックを見つけ出し、パフォーマンスを最適化します。

高負荷条件下でシステムの安定性をテストします。

過負荷状態でのシステムの電流制限と劣化計画を検証します。

3. 圧力試験がないと、どのような問題が発生しますか?

オンライン キャパシティ アセスメントが不正確で、トラフィックが増加し、サービスが中断される

アップグレード前に圧力テストが行​​われておらず、アップグレード後にパフォーマンスが低下し、使いやすさが低下しました。

正確なコミットメント値を与えることができないため、クラスターの水位が低くなり、リソースが浪費されるか、クラスターの水位が高くなり、システムの安定性のバグが発生します。

02 圧力測定スキームの設計

ストレス テスト環境は、モジュール レベルのストレス テストとリンク レベルのストレス テストに大別できますが、主な機能と相違点は次のとおりです。

1. モジュールレベルのストレステスト

適用シナリオ: 変更前後の性能を比較し、性能が低下しているかどうかを確認し、モジュール自体の性能のボトルネックを突き止めます。

環境要件: オンライン環境と完全に一致する必要はなく、変更前と変更後の 2 つの圧力テストが同じ環境であることを確認するだけで十分です。

業界ソリューション: 固定されたオフライン環境を維持し、定期的および通常のストレス テストを実施します。

2. リンクレベルのストレステスト

アプリケーション シナリオ: リンク全体の容量を評価するため、システムの全体的な可用性を評価するため。

環境要件: 可能な限りオンライン環境と一致することが要求されます.このようなストレス テスト データのみが参考として使用できます.

業界ソリューション: オンライン環境を使用し、さまざまな分離方法に応じてさまざまなソリューションを使用します。

• トラフィック分離なし、圧力テスト トラフィックとビジネス トラフィックが共存します。分離がないため、オフピーク時にのみ圧力テストを実行できます。 

• 圧力テスト トラフィックは、トラフィックのスケジューリングまたは分散を通じて論理的に分離され、圧力テスト環境に送信されます。圧力テスト トラフィックとビジネス トラフィックは同じコンピューター ルームで実行されますが、同じビジネス インスタンスに到達するわけではありません。

• さまざまな場所でのマルチアクティブ機能を利用して物理的に分離すると、1 つのコンピューター ルームからビジネス トラフィックが切り離され、ストレス テスト用の空のコンピューター ルームが残ります。

最初のソリューションは、オンラインの実環境に最も近いですが、いくつかのセキュリティ リスクがあります。後者の 2 つのソリューションは、はるかに安全ですが、オンライン アーキテクチャ全体を十分に活用しておらず、ある程度の歪みがあります。

3. オンライン ストレス テストの安全性を確保する方法は?

• トラフィックの分離については、前述のようにトラフィックの分離を実行します。ただし、トラフィックの分離だけでは十分ではなく、物理的な分離でもオンライン データが変更されるため、データの分離も必要です。

• 圧力テスト トラフィックがミドルウェアを通過するときに、それをマークして圧力テスト マークを作成します (たとえば、http トラフィックは特別なヘッダーで構成できます)。

• トラフィックのストレス テストによって生成されたログを別のパスに書き込む (一部のシステムではログを分析してカウントする) など、ビジネス クラスター内のトラフィック マーキングに対してデータの分離が行われ、ストレージ/キャッシュに関しては、ストレス テストによって生成されたデータが格納されます。シャドウ テーブルのトラフィック、通常のトラフィックは通常のテーブルにアクセスします。

• メッセージ シールド。メッセージ キューがプレッシャー テスト メッセージを認識できない場合、オンライン メッセージの蓄積が発生し、オンライン トラフィックに影響を与えるため、プレッシャー テスト メッセージをシールドする必要があります。

• 圧力テストをサポートしないサードパーティ サービスのモックを作成します。

03 圧力測定モデル

圧力テストはどのようなシナリオをカバーする必要がありますか? 圧力テストのリクエストとデータはどのように作成されますか? ビジネス トラフィック パターンをシミュレートする方法 上記の 3 つの質問は、ストレス テスト モデルのビジネス モデル、データ モデル、およびトラフィック モデルに対応しています。

1. ビジネスモデル

ストレス テストでカバーする必要があるビジネス シナリオは?

主要なビジネス シナリオを整理する必要があります, これには、コア インターフェイスと高トラフィック インターフェイスが含まれている必要があります. 高トラフィック インターフェイスは、ユーザーに公開されておらず、内部で頻繁に使用されるインターフェイスである可能性があります.

ビジネスシナリオをシミュレートする方法は?

インターフェイス間の関係を明確にする必要があります。いくつかの単純なクエリ インターフェースでは、前後の依存関係がなく、トラフィックの比率に注意するだけでよく、複雑なビジネス シナリオでは、業務処理フローを復元してインターフェース シリーズのロジックを明確にする必要があります。シーンの記録とシーンの再生で整理できます。

2.データモデル

オンラインデータに基づく変換

要求部分は、オンライン トラフィックを直接記録し、圧力テストで要求をマークし、キー ID を安くすることができます; 基本データは、オンライン ストレージ データを別の圧力テスト テーブルに直接コピーできます。

モデルベースの構築

オンラインのログやリクエストを分析することで、パフォーマンスに影響を与えるデータの特徴やリクエストの特徴を整理し、それらの特徴に基づいてデータを構築し、基になるデータを実際の業務アプリケーションを通じて構築する必要があります。

オンラインデータによる変革のあり方

ソリューションはシンプルで、データ構造は高速ですが、システム内の既存のデータは新しいシナリオに対応できず、モデルの調整は柔軟ではないため、古いサービスのオンライン圧力テストに適しています。

モデルベースの構築

オンライン データに大きく依存せず、新しいシーンを手動で構築でき、メンテナンス コストが低い. インターフェイスを調整するだけでよく、オンライン ストレージ テーブルの変更を認識する必要がない. モデルは柔軟に調整できるが、スキームはより複雑で、データ構造は遅いです. 使用シーンは比較的広く、オンラインとオフラインの両方で新旧のサービスが利用可能です.

圧力テスト モデルの特殊なケース:トラフィックの記録、そのままの再生

機能: ビジネス シナリオをシミュレートする必要はなく、データを構築する必要もありません。サービスと既存のオンライン トラフィックとのインターフェイスを記録するだけです。オンライン環境で再生するだけで、読み取り専用インターフェイスのみです。古いサービスの読み取りインターフェイスの圧力テストにのみ適用できます。

トラフィック記録は、低ピーク期間、フラット ピーク期間、およびピーク期間のトラフィックを記録して、検出の見逃しを回避できます。

3. トラフィック モデル:ビジネス トラフィック パターンをシミュレートする

• オンラインでトラフィックがあります

  オンライン トラフィック パターンを観察します。

  インターネット上のオープンソース監視管理のほとんどは 5 秒以上であり、理想的には、ログを分析することで実現できるミリ秒レベルに達することができます。

• オンラインでトラフィックがありません

  ユーザーの行動や発信者の行動を分析します。

  一般的なビジネストラフィックのパターンは、連続増分型とパルス型（赤い封筒をつかむなど）の 2 種類に分けられます。

4.交通量予測

フロー パターンはアナログのオンライン フロー カーブであり、さらに、フローを推定し、圧力測定値の大きさを計算する必要があります。

Double Eleven を例にとると、インターフェイスを 3 つのカテゴリに分けることができます。

• バックグラウンド インターフェイス

  トラフィックはアクティビティによって変化せず、圧力測定はバックグラウンド トラフィックとしてのみ使用され、最近のピーク値を取得できます。

• 共通の関心事のインターフェース

  フローはアクティビティによって異なり、一般的なモデルで計算されます

• Chongbao インターフェイス

  たとえば、過去のプロモーションのピーク値を取得するトランザクション インターフェイス

04 耐圧試験結果の分析

1. 観測指標

システムインジケーター

• qps/tps、最大 tps は安定している必要があります。ジッターがある場合は、システムにすでに問題があります。

• 応答時間、クライアントがリクエストを開始してからリクエストを受信するまでの全プロセス時間

• sla によるエラー率

• リソース インデックス

• CPU 使用率、通常 80% 未満、平均 60% 未満がより安全

• メモリ使用量は 80% 未満が安全です。それ以外の場合は、GC デス サイクルに陥る可能性があります。

• ディスク スループット/ネットワーク スループット

• 特定の事業に応じて決定される機能指標

• 接続プールの使用

• メッセージ待ち行列の累積

• pps

2. シミュレーション度分析:ストレス テストの結果は価値があるか?

同じ水位でのストレス テスト シナリオとオンラインの実際のシナリオのサービス パフォーマンスの類似性を比較すると、シミュレーション分析に使用できる指標は次のとおりです。

• 流量、流量比、界面被覆率

• リンクカバレッジ

• マシン リソース、CPU 使用率、メモリ使用率

• 可用性指標、レイテンシ、エラー率

• ビジネス指標

これらの指標をベクトルにまとめてオンライン指標と比較すると、両者の差が小さくなり、シミュレーションの度合いが高くなります。

05 応力測定の開発動向

既存の問題点:

• いつでも観察および監視する必要があり、オンコールスタンバイが必要

• セキュリティの欠如

• スキームは複雑で高価です

今後の傾向:

• 知的

• 無人

最後に: 熱心なファンに恩返しをするために、完全なソフトウェア テスト ビデオ学習チュートリアルを作成しました. 必要な場合は無料で入手できます.【保证100%免费】

これらの資料は、[ソフトウェア テスト] の友人のための最も包括的で完全な準備倉庫である必要があります. この倉庫はまた、最も困難な旅を通して何万人ものテスト エンジニアに同行しています. それがあなたにも役立つことを願っています.

完全な情報を取得する方法: