序文
メジャー昇格に向けたストレステストは、現段階では新しいことではなく、技術的なボトルネックやリソースの問題はなく、各チームにパフォーマンステストを実施できる人材が多数おり、すでに日課として実施しているチームもあるが、ストレス テストは、単にストレス テスト プラットフォームでパラメーターを設定し、スクリプトを実行し、ストレス テスト レポートの特定の指標がストレス テストの目標を満たしているかどうかを確認するほど単純ではありません。クラスメート数人とパフォーマンス テストも行ったところ、次のことがわかりました。ストレス テストのプロセスには、いくつかの詳細な問題があります。テストを行っても、十分に理解していない学生もいます。ストレス テスト プログラムは、パフォーマンス テストの中でも特に重要な部分です。今日は、ストレス テスト プログラムについての理解を説明します。 ;
パフォーマンス テストの本質は、運用環境でユーザーをシミュレートし、ユーザーの実際の動作要求を構築し、ストレス テスト システムに可能な限り現実的な圧力をかけ、システム パフォーマンスがビジネス ニーズを満たしているかどうか、およびパフォーマンスのボトルネックがあるかどうかを検証することです。
そこから、ストレス テストの目標、ストレス テストのシナリオ、ストレス テストの環境といういくつかの核となるポイントがわかります。今日は主に 3 つの主要な部分に焦点を当てます。
1. ストレステストの目標
私たちがストレス テスト計画を策定し、ストレス テストの目標について話していたとき、多くの学生が TPS、QPS、TP99 を直接検討しました。
無視されてきた非常に重要なことは、ストレス テストの背景です。だからこそ、このストレス テストを実施したいのです。ストレス テストの背景は、ストレス テストの方向性です。方向性が間違っていると、時間を無駄にすることになります。耐圧試験終了後の努力と耐圧試験の結果は意味がない
では、ストレス テストの背景とストレス テストの目標にはどのような関係があるのでしょうか?
現在わかっているいくつかの一般的なストレス テストの背景について話しましょう。
1. 大キャンペーン期間中、通常時と比べて電話件数が大幅に増加した事業者
目標: 大規模なプロモーションの推定ピーク トラフィック (ビジネスの見積もり + ビジネスの成長 + 大規模なプロモーションの成長) + 1 つのコンピューター ルームの収容能力 + インターフェイスがサポートできる通話量をサポートできるかどうか
結論: 最適/最大スループット xxx を備えた xxx 構成は、このプロモーション xxxx の推定ピーク コール量をサポートできます。リスクはありますか?
2. 前回の大規模なプロモーション中にストレステストが行われたが、それ以降に追加/変更されたコンテンツ
目標: インターフェイスのパフォーマンスが変化したかどうか + 大規模なプロモーションの推定ピーク トラフィックをサポートできるかどうか + インターフェイスがサポートできるコールの量
3. 新しく追加されたインターフェイスはストレス テストが行われていないため、ビジネス コールの量は推定されています。
目標：業務通話量の見積もり（限度額）＋通常をインターフェースが満たせるか
4. 新しく追加されたインターフェイスはストレス テストされておらず、ビジネス コールの量は見積もられていません。
目標: インターフェイスのパフォーマンス評価。システム パフォーマンスにボトルネックはありますか? 最適化の余地はあるでしょうか?
5. 新しいインターフェースが古いインターフェースを置き換えます
目標：インターフェースの性能評価、旧インターフェースの営業通話量＋新インターフェースの営業通話量を満たせるかどうか
6. 古いインターフェースのパフォーマンスの最適化
目標: 最適化の前後でパフォーマンス指標を比較し、最適化の効果があるかどうかを確認します。
7. 大規模なプロモーション期間中、ピーク時の通話量は 1 日の通話量と比べて大きく変わりませんが、ビジネスのピーク時間は長くなります。
目標: ピーク流量安定性圧力試験
8. 通話量はそれほど多くありませんが、ユーザーはユーザー エクスペリエンスに対して比較的高い要求を持っています。
目標: インターフェイスの応答時間に知覚的な遅延はありますか? TP99 に注意を払い、最適化する必要があるかどうかを確認してください。
9. システムを拡張する必要があるかどうかわかりません。
目標: 極度のストレス テスト、アプリケーション サーバーとデータベースのリソース使用量が妥当かどうか
10. リンクとインターフェイスのパフォーマンスが比較的遅いことが知られていますが、ボトルネックがどこにあるのかを知る必要があります。
目標: リンクおよびインターフェース システムの弱点を見つける (コンテンツは最適化可能)
2. ストレステストのシナリオ
ビジネスモデルの調査と構築は、プレストレステスト業務の最も核心となる部分であり、実際の本番環境システムの業務運用形態に基づいたビジネスモデルの構築が必要であり、実際の本番環境のシステム業務利用形態に適合している場合に限ります。 , パフォーマンス テストの結果は、オンライン化後のシステムのパフォーマンスを真に効果的に反映します。ビジネス モデリングの品質は、パフォーマンス テスト実行の成功を直接決定します。これをストレス テスト モデルと呼びます。
ビジネス モデリング プロセスでは、次の 3 つのことを明確に分析する必要があります。
1. トラフィックを生成するシナリオは何ですか? ストレス テストが必要なシナリオを選択するにはどうすればよいですか?
2. さまざまなシナリオとトランザクション間のトラフィックをどのように分散および設計するか?
3. テストの目標を達成するには、どのくらいのフロア データを構築する必要があり、このフロア データをどのように配布および展開する必要があるか? さらに、ビジネス モデル設計データが必要であり、データをどのように配布および構造化する必要があります。
実際、行う必要があるのは、ビジネスを明確に理解し、それに基づいてビジネス モデル、トラフィック モデル、データ モデルを完成させることです。
1. ビジネスモデル
一般に、ビジネス運営の観点、技術的運営の観点、オンラインの問題分析とテストの経験という 4 つの側面から収集、整理、洗練されます。
ビジネス運用: 実際のビジネス アプリケーションの観点から、実際のユーザーの使用状況とビジネスの成長傾向を収集します。たとえば、ビジネス通話のソースがいくつかあります。ユーザーが通常最もよく使用するシナリオは何ですか? ユーザー操作のピーク時間は何時ですか?
技術的操作: 技術的操作の観点から、インターフェイス実装ロジックの呼び出しリンクを整理します。たとえば、ディスパッチ ワークベンチ行が展開されてクエリが実行される場合、その行の下にあるタスクが 20 未満の場合、例外インターフェイスが調整されます。 ; タスクが 20 を超える場合、例外インターフェイスは調整されません。たとえば、キャッシュまたはデータベースを介してクエリ インターフェイスを実装する方法。
オンラインの問題: ユーザーのフィードバックとオンラインの問題の収集に基づいて、オンラインの問題修復方法と組み合わせます。たとえば、xxx 操作の応答が遅いと認識されるという最前線のフィードバック、これを最適化する際に研究開発がカバーするユーザー操作シナリオ?
テスト経験：テスト経験をもとにビジネスモデルを改善
2. トラフィックモデル
ビジネスシナリオが決まったら、さまざまなシナリオやトランザクション間でトラフィックを分散する方法を考える必要があります。。
本番環境でのユーザーの操作シナリオは比較的複雑であり、リクエストパケットのサイズやリクエストパスも異なるため、ストレステストに単一のリクエストパケットを使用するのは合理的ではありません。モデル分析。それは、ユーザー行動モデルとシステムビジネスモデルです。
ユーザー行動モデル: ピーク時のユーザー行動の特徴を記述し、ユーザー行動の調査と分析を通じてユーザー行動モデルを要約します。より一般的なのは、現在のトラフィック記録です。これは、ビジネスのピーク時間帯にビジネス トラフィックを記録し、そのトラフィックを再生します。利点は実装が比較的簡単であることですが、欠点は、記録されたトラフィック ユーザーの行動を統計的に把握することが難しいことです。分析する。
システム ビジネス モデル: ピーク時のシステム ビジネス特性に基づいて、システム ログ、データ ポイントなどを通じてピーク時のシステム ビジネス トラフィックを取得し、ユーザーの主なトラフィック動作を学習し、スクリプトを作成してトラフィックの割合を構成することで実装します。利点 ユーザーのトラフィックの割合が比較的明確ですが、欠点はデータを手動で分類および分析する必要があることです。
3. データモデル
ビジネス モデルとトラフィック モデルを設計した後、どれだけの基本データ (フロア データとも呼ばれる) が必要かを知る必要があります。フロア データの目的は、オンライン テスト (少なくとも数量分布) と可能な限り一致することです。一貫性があります)、データベースの種類に関係なく、データのボリュームが異なると、使用されるクエリ オプションも異なります。数百行のデータに対する完全テーブル スキャンは、インデックス スキャンよりも明らかに優れていますが、数百万行がある場合はどうなるでしょうか? これにより、詳細な評価が容易になります。一般に、データ量は実際の運用環境のデータ量に基づいて決定し、パフォーマンス テスト環境では同等のデータ量を置き換える必要があります。
概要: ユーザーの数 (WHO) いつ、どのくらいの期間 (When)、データの量 (How much) に基づいて、どのようなビジネスが完了したか (What)、そして最後にどの指標に焦点を当てる必要があるか (How)。
例：
単一インターフェイスのストレス テスト (さまざまな呼び出し方法):
1. デフォルトのページでは自動クエリが開きます。デフォルトのクエリは 1 ページあたり 20 レコードであり、これが最大のユーザー フォームでもあります。
2. インターフェイスを通じて呼び出され、インターフェイスによって返されるページごとのアイテムの最大数は 1,000 です。
単一インターフェイスのキャッシュ ストレス テスト:
- 10 分間のウォーク キャッシュ
- 10分間キャッシュをキャッシュしない
- 部分的なキャッシュ ヒット、部分的なキャッシュ ミス、10 分ごとに 5 分間のキャッシュ エラー
単一インターフェイス混合シナリオのストレス テスト:
スケジュールワークベンチ - ユーザー権限およびさまざまなユーザー動作内の行をクエリするためのページング
1. 1 日あたり 1 つのエリアのクエリ
2. 1 日で 7 つの地域のクエリ量
3. 3 つの混合シナリオ (7 日間で 1 エリア 10%、1 日で 7 エリア 20%、1 日で 1 エリア 70%)
単一アプリケーションのマルチインターフェースハイブリッド圧力テスト:
通話量に基づくインターフェース呼び出しの割合
単一サービス インターフェイスのハイブリッド ストレス テスト:
該当するシーン:
操作インジケーター ダッシュボード (大画面ページにリンクされており、約 150 人の共通ユーザーが含まれます) は、ユーザーが大画面にアクセスすると、次の 5 つのインターフェイス メソッドを呼び出します。
ユーザーが最初にページに入った後、クエリ条件なしでデフォルトで 5 つのインターフェイスが呼び出されます。
ユーザーがこのページに留まると、ページのコンテンツは 30 秒ごとに自動的に更新され、5 つのインターフェイスが呼び出されます。
ユーザーがクエリ条件を手動で入力し、クエリをクリックすると、クエリ操作が自動的に実行され、5 つのインターフェイスが呼び出されます。
極度の圧力テスト:
[618 準備ストレス テスト - コア プロセス極度ストレス テストの実行] テスト計画
ダブルインスタンスの線形成長の検証
完全なリンク ストレス テスト:
[618パフォーマンステストの準備-輸送ORC受注]パフォーマンステストレポート
システム安定性ストレステスト
ビジネス要件を満たした後、一定期間 (4 ～ 6) 加圧を続けて、システムの安定性を確認します。
3. ストレステスト環境
1. オンライン環境を優先する
2. ストレス テスト環境と運用環境のスループットの違い シングル インスタンスのストレス テストとデュアル インスタンスのストレス テストのどちらを選択すればよいですか?
3. ストレステスト環境と本番環境の違い
4. 耐圧試験環境と本番環境のデータ量の違い
著者: JD Logistics Zhu Fei
出典：JD Cloud Developer Community Ziyuanqishuo Tech 転載の際は出典を明記してください
Alibaba Cloudが深刻な障害に見舞われ、全製品が影響(復旧) Tumblr がロシアのオペレーティングシステムAurora OS 5.0 を冷却新しいUIが公開 Delphi 12とC++ Builder 12、RAD Studio 12多くのインターネット企業がHongmengプログラマーを緊急採用UNIX時間17 億時代に突入しようとしている (すでに突入している) Meituan が兵力を募集し、Hongmeng システム アプリの開発を計画Amazon が Linux 上の .NET 8 への Android の依存を取り除くために Linux ベースのオペレーティング システムを開発独立した規模はFFmpeg 6.1「Heaviside」がリリースされました