1. はじめ
に 5G 時代と Internet of Everything 時代の到来により、クラウドアプリケーションやクラウドサービスはますます増加し、データ量は飛躍的に増加します。特に、2020 年の世界的な感染症の画期的な重要性により、あらゆる階層がクラウドへの移行を開始することになります。これにより、個性豊かなさまざまな商品が誕生します。
あらゆる産業の生態系は、いくつかの巨大企業を中心に、人々のさまざまなニーズを満たす中小規模の製品を生み出す、クジラの落下効果のようなものになるでしょう。ほとんどの製品の形式は、サーバーでは重くなり、クライアントでは軽くなる可能性があります。
したがって、サーバー側のパフォーマンステストの需要も急増する可能性があります。ただし、中小企業、特にユーザーエクスペリエンスに注意を払わない企業の場合、サーバーのパフォーマンステスト要件は短いサイクルと厳しいスケジュールによって特徴付けられます。
したがって、ほとんどのテスト実施者にとって、頻繁に使用されるわけではありませんが、一般的なパフォーマンステストの知識を理解し、習得することが不可欠です。
2. パフォーマンスとは何ですか?
さまざまな役割がさまざまなパフォーマンスに焦点を当てています。パフォーマンステストの体系的なプロジェクトとして、各役割は注意力の範囲内で情報を提供したり支援したりする必要があります。
ユーザーの目から見たパフォーマンスユーザー
にとって、パフォーマンスとは操作の応答速度であり、製品のクラッシュが生活に影響を与えるかどうかを指します。例えば、バレンタインデーのDidiタクシーサービスのパフォーマンス事故。
ここに画像の説明を挿入

上司から見たパフォーマンス上司は
主に、製品の収益、コスト (何人のユーザーにサービスを提供するためにどれだけの金額が使用されるか)、およびユーザー満足度 (ユーザーが製品に満足しているかどうか) を重視します。

ここに画像の説明を挿入

運用の目から見たパフォーマンス

ここに画像の説明を挿入

開発者の目から見たパフォーマンス
ここに画像の説明を挿入

テストの観点から見たパフォーマンス
ここに画像の説明を挿入

3. パフォーマンスの影響
3.1 ユーザーに対するパフォーマンスの影響
ほとんどの営利企業の ToC 製品では、パフォーマンスは製品の運命と成長に関係しています。下図のように、Ali JD.comの独占下にあるアプリケーションを置き換えるのは簡単ではありませんが、パフォーマンスが悪い場合は、それでも心の中で一言を言わずにはいられません。
ここに画像の説明を挿入

3.2 収益に対するパフォーマンスの影響
パフォーマンスが製品の収益に非常に大きな影響を与えることは誰もが知っていますが、これを証明するための包括的な運用分析を行っている企業はほとんどありません。
以下は、2016 年のグローバル小売デジタルパフォーマンスベンチマークレポートからの、収益に対するパフォーマンスの影響に関するデータです。
図からわかるように、応答時間はコンバージョン率に大きな影響を与えます。たとえば、ウォルマートは十分にハードコアですが、ウォルマートの応答時間が 0.1 秒短縮されれば、収益は 1 増加する可能性があります。 %、これは収益の非常に大幅な増加です。
ここに画像の説明を挿入

4. 性能構成
中小規模のECサイトを例に挙げると、基本的な性能構成は下図のようになります。
クライアント（Web、モバイル端末、アプレット）性能

DNSのパフォーマンス

負荷分散サービスのパフォーマンス

Nginx クラスターのパフォーマンス、損失率

CDN キャッシュのパフォーマンス (バックトゥソース率、浸透率)

アプリケーションサーバーのパフォーマンス

DB パフォーマンス (Mysql/Redis/Memcache)

中大規模プロジェクトのパフォーマンステストは、常に組織的なプロジェクトであり、部門を超えて多くの人々の協力が必要であり、長期にわたって多くのリソースを消費することがわかります。
ここに画像の説明を挿入

5. パフォーマンステストの基礎知識と注意事項
パフォーマンステストに慣れる前に、まずパフォーマンステストの目的を理解してください。目標を持って考えると、次の内容の理解が促進されます。
5.1 パフォーマンステストの目的
パフォーマンステストの最終的な目的は、ユーザーのニーズに最大限応えることであり、通常は次の目標を達成することです。 (1)
パフォーマンス評価: パフォーマンステストの QPS、応答時間、成功率などを評価します。 (2)システムを見つける
(3)
ソフトウェアの問題を検出する
(4) 安定性と信頼性を検証する;
5.2 パフォーマンスに関して考慮すべき指標
一般に、パフォーマンステストでは次の要素を一律に考慮する必要があります。、遅延応答時間、リソース使用率 (CPU/MEM/IO/帯域幅など)、成功率、システムの安定性。
(1) 応答時間: システム応答時間の遅延を定義する必要があります。これは TP95 以上であることが推奨されます。応答時間の具体的な要件は何ですか? 通常、読み取りは 200 ミリ秒を超えず、書き込みは 500 ミリ秒を超えません。本当にわからない場合は、同じ業界の競合製品と比較してベンチマークを行ってください。
(2) 最大スループット: TPS (1 秒あたりのトランザクションリクエスト数) または QPS (1 秒あたりのリクエスト数)、目標応答時間要件の下でシステムがサポートできる最高のスループット。
(3) 成功率: QPS と応答時間に注意を払う一方で、成功率にも注意する必要があります。QPS と応答時間の両方がパフォーマンス要件を満たしている場合、リクエストの成功率は 50% にすぎず、ユーザーはリクエストを受け入れません。
(4) パフォーマンスの変曲点: 一般的なサービスにはパフォーマンスの臨界点があります。臨界点を超えると、スループットは非線形に減少し、応答時間は指数関数的に増加し、成功率が低下します。
パフォーマンス変曲点の主な理由を見つけます。
パフォーマンス変曲点の主な理由に基づいて、高リスクのパフォーマンスアラームラインを設定します。パフォーマンスの変曲点に達すると雪崩が発生し、非常に重大な事故につながる可能性があるため、これは一か八かの予防策です。
パフォーマンスの変曲点を超えた後に、一時停止アニメーションやシステムのクラッシュなどの高リスクのイベントが発生するかどうかを監視します。
(5) システムの安定性: 最高のスループット (目標応答時間内での最高のスループット) を維持し、7*24 時間連続的に実行します。次に、CPU、メモリ、ハードディスク/ネットワーク IO などの指標を収集して、システムが安定しているかどうか (CPU が安定しているか、メモリ使用量も安定しているかなど) を確認します。そして、この値がシステムのパフォーマンスになります。
(6) 究極の処理量:同時圧力を段階的に増加させてシステムの限界値を見つけます。例: 成功率が 100% の場合 (応答時間の長さに関係なく)、システムは 10 分のスループットを維持できます。
(7) システムの堅牢性: バーストテストを実行します。2 番目のステップで取得したスループットを使用して 5 分間実行し、次に 4 番目のステップで取得した制限値を 1 分間実行し、その後 2 番目のステップのスループットに戻って 5 分間実行し、次に権限値を実行します。 4 番目のステップは 1 分間なので、2 日間など、一定期間行ったり来たりします。システムデータ (CPU、メモリ、ハードディスク/ネットワーク IO など) を収集し、それらの曲線と対応する応答時間を観察して、システムが安定していることを確認します。
(8) 低スループットおよび小規模ネットワークパケットテスト: スループットが低い場合、遅延が増加することがあります。たとえば、TCP_NODELAY パラメーターが有効になっていない場合、遅延が増加し (詳細については TCP を参照)、ネットワークが小規模になります。パケットの帯域使用率が不十分になり、パフォーマンスの低下につながるため、パフォーマンステストでも、実際の状況に応じてこれら 2 つのシナリオを選択してテストする必要があります。
5.3 パフォーマンステストの種類
まず、パフォーマンステストのストレスモデルを簡単に分析します。
以下の図に示すように、単位時間あたりの圧力が増加し続けると、テスト対象のシステムとサーバーにかかる圧力が増加し続け、TPS はこれらの要因によって変化し、通常は次の規則に従います。
ここに画像の説明を挿入

ここに画像の説明を挿入

パフォーマンスに関する懸念の指標を取得するために、パフォーマンステストは基本的に次の種類に分けられます。
パフォーマンステスト (狭義)

説明: パフォーマンステスト方法は、運用操作のビジネスプレッシャーと使用シナリオの組み合わせをシミュレートすることにより、システムのパフォーマンスが運用パフォーマンス要件を満たしているかどうかをテストします。平たく言えば、この方法は、特定の動作条件下でシステムの機能状態を検証することです。

特徴: 1. この方法の主な目的は、システムが主張する機能をシステムが備えているかどうかを検証することです。2. この方法では、テスト対象システムの古典的なシナリオを事前に知っておく必要があり、明確なパフォーマンス目標があります。3. この方法は、あらかじめ定められた環境での運用が必要となります。つまり、この方法は、システムの性能を理解していることが前提であり、要求の目標が明確であり、あらかじめ定められた環境で実行される。

負荷テスト

説明: パフォーマンス指標 (「応答時間」など) が所定の指標を超えるか、一部のリソースが飽和に達するまで、テスト対象のシステムに継続的に圧力を加えます。

特徴: 1. このパフォーマンステスト方法の主な目的は、システムの処理能力の限界を見つけることです。2. このパフォーマンステスト方法は、特定のテスト環境で実行する必要があり、テスト結果がビジネス上重要になるように、通常はビジネス上のプレッシャーとテスト対象システムの典型的なシナリオも考慮する必要があります。3. このパフォーマンステスト方法は、通常、システムのパフォーマンス能力を理解するため、またはパフォーマンスチューニングと組み合わせて使用するために使用されます。言い換えれば、この方法はシステムに継続的に圧力をかけ、いつ「私の要件」を超えたか、システムがクラッシュしたかを確認することです。

ストレス試験（強度試験）

説明: ストレステスト方法では、CPU やメモリの使用量など、特定の飽和状態でセッションを処理するシステムの能力と、システムに障害が発生するかどうかをテストします。

特徴: 1. このパフォーマンステスト方法の主な目的は、システムに負荷がかかっているときのアプリケーションのパフォーマンスをチェックすることです。2. この種のパフォーマンステストでは、通常、システムのリソース使用量をより高いレベルに到達させるために、負荷のシミュレーションなどの方法が使用されます。3. このパフォーマンステスト方法は、通常、システムの安定性をテストするために使用されます。言い換えれば、この種のテストは、システムに大きな負荷をかけて、システムが安定しているかどうか、どこに問題があるかを確認することです。

同時実行テスト¶

説明: 同時実行テスト方法は、同時ユーザーアクセスをシミュレートして、複数のユーザーが同じアプリケーション、同じモジュール、またはデータレコードに同時にアクセスするときにデッドロックやその他のパフォーマンスの問題が発生するかどうかをテストします。

特徴: 1. このパフォーマンステスト方法の主な目的は、システム内の潜在的な隠れた同時アクセス問題を発見することです。2. このパフォーマンステスト方法は、システム内のメモリリーク、スレッドロック、リソース競合の問題など、システム内で発生する可能性のある同時実行の問題に主に焦点を当てています。3. このパフォーマンステスト方法は開発のさまざまな段階で使用でき、関連するテストツールの協力とサポートが必要です。つまり、このタイプのテストは、複数のユーザーが同時に (同時に) モジュールまたは操作にストレスを与えることに焦点を当てます。

構成のテスト¶

説明: 構成テスト方法は、テスト対象システムのソフトウェアおよびハードウェア環境を調整して、システムのパフォーマンスに対するさまざまな影響の程度を把握し、さまざまなシステムリソースの最適な割り当て原則を見つけます。

特徴: 1. このパフォーマンステスト方法の主な目的は、システムパフォーマンスに対するさまざまな要因の影響の程度を理解し、最も価値のあるチューニング操作を決定することです。2. この性能テスト方法は、通常、システムの性能状態を事前に把握した上で実施されます。3. このパフォーマンステスト方法は、通常、パフォーマンスのチューニングと計画機能に使用されます。つまり、この種のテストの焦点は、システムが最も強力な状態に到達できるように、ソフトウェアとハードウェアの調整を通じてそれらの最適な状態を見つける「微調整」です。

信頼性試験

説明: システムに一定のビジネス圧力 (たとえば、リソースの使用率が 70% ～ 90%) をかけて、システムを一定期間稼働させ、システムが安定して稼働しているかどうかを検出します。

特徴： 1. この性能試験方法の主な目的は、長期安定稼働をサポートするかどうかを検証することです。2. この性能試験方法では、一定期間、圧力下での連続運転が必要です。(2~3日) 3. テスト中はシステムの稼働状況に注意する必要があります。テスト中に、時間の経過とともに応答時間が大幅に変化するか、システムリソースの使用量が大幅に変動することが判明した場合は、システムが不安定になっている兆候である可能性があります。言い換えれば、この種のテストの焦点は「安定性」であり、システムが長時間安定した状態を維持できる限り、システムに過度の負荷をかける必要はありません。

フェイルオーバーテスト

説明: システムの部分的な障害が発生した場合にユーザーがシステムの使用を継続できるかどうか、および障害が発生した場合にユーザーがどの程度影響を受けるか。

特徴： 1. この性能試験方法の主な目的は、部分的な故障が発生した場合でもシステムが継続して使用できるかどうかを検証することです。2. この性能試験方法では、問題が発生した場合に「どれだけのユーザーアクセスに対応できるか」の結論と「どのような緊急対策を講じるか」の計画も示す必要があります。3. 一般に、このタイプのテストは、継続的なシステム動作インジケータに対する明確な要件があるシステムにのみ必要です。

大容量データテスト: 特定のシステムストレージ、送信、統計クエリ、その他のサービスについて大容量データをテストします。

注: パフォーマンステストを行うときは、並べ替えを忘れてください。たとえば、システムが信頼できるかどうかをテストするために 8 時間実行します。このテストには、信頼性パフォーマンステスト、強度テスト、同時実行テスト、負荷テストなどが含まれる可能性があります。したがって、パフォーマンステストを実装するときは、内部接続を切り離すのではなく、テストの目的に基づいてそれらの関係を分析し、効率的な方法でパフォーマンステストを設計する必要があります。
5.4 パフォーマンステストのプロセス
ここに画像の説明を挿入

(1) 性能要件分析
性能要件分析は性能試験作業全体の基礎となるものであり、性能要件が明確でなければ、その後の性能試験ツールや実装も問題になりません。
この段階では、パフォーマンステスターは PM、DEV、プロジェクト関連担当者とコミュニケーションをとり、さまざまなプロジェクトデータを収集し、システムを分析し、テストの目標を確認する必要があります。そしてそれを具体的な測定可能なパフォーマンス指標に変換します。
テスト要件分析段階の主なタスクは、テスト対象のシステムとそのパフォーマンス要件を分析し、パフォーマンステストデータモデルを確立し、パフォーマンス要件を分析し、合理的なパフォーマンス目標を決定し、レビューを実施することです; (2) パフォーマンステストの準備には主に以下が含まれます。シナリオ
に応じた設計
シナリオプログラムの作成、スクリプトの作成、テスト環境の準備、テストデータの構築、環境の事前チューニングなど;
設計シナリオ: システムの特性に応じて合理的なテストシナリオを設計します。テスト結果をより正確にするために、ここでは慎重な作業が必要です。たとえば、ユーザーモデルを確立するには、実際のユーザーがシステムにどのような圧力をかけるかを知ることによってのみ、代表的なストレステストシナリオを設計できます。これには、ユーザーグループの分布、さまざまなタイプのユーザーが使用する機能、ユーザーの習慣、作業時間、システムの各モジュールの圧力分布など、多くの情報が関係します。このようなデータを多面的に継続的に蓄積することによってのみ、ストレスシナリオはより意味のあるものになります。最後に、設計シナリオは具体的なユースケースに変換されます。
テストデータ: テストデータの設計も重要なポイントですが、問題が発生しやすくなります。将来的に想定される量に達するためのテストデータを生成するのは最も基本的なステップに過ぎませんが、考慮する必要があるのはデータの分布が合理的であるかどうかであり、テストで使用されるさまざまなクエリ条件を注意深く確認する必要があります。これらのキー列の値は、可能な限り現実のデータ分布をシミュレートする必要があり、そうでない場合は、テスト結果が無効になる可能性があります。テストデータには、実際のユーザーの行動にできるだけ近いオンラインの感度を下げたデータを使用するのが最善です。
プレチューニング: テスト実行中の不必要なやり直しを避けるために、システムの特性やチームの経験に応じてシステムのさまざまな側面を事前に最適化および調整することを指します。たとえば、同時実行性の高いシステムで、10,000 人がオンラインで、接続プールとスレッドプールのデフォルト構成が引き続き使用されている場合、明らかに問題が検出されます。
(3) 性能試験を実施する
実行フェーズの作業には主に 2 つの側面が含まれます: 1 つは、実行スクリプトとシナリオを含むテストケースモデルの実行であり、2 つ目は、テスト結果を含むテストプロセスの監視、パフォーマンスインジケーターとパフォーマンスカウンター値の記録 (4) ) 結果の分析とパフォーマンスの
調整
問題が見つかった場合、またはパフォーマンス指標が期待を満たしていない場合は、タイムリーに分析して特定し、処理後にテストプロセスを繰り返します。
通常、パフォーマンスの問題は相互に関連し、影響し合っており、表面に見られる現象は根本的な問題ではなく、別の問題によって引き起こされた反応である可能性があります。そのためには、データを総合的に監視・収集し、さまざまな側面や観点から判断・位置付けする必要があります。チューニングのプロセスは実際にはバランスのプロセスであり、システムのさまざまな側面でバランスを達成するだけで十分です。
(5) パフォーマンスレポートと概要
パフォーマンステストの目的、パフォーマンス結果、テスト環境、データ構造のルール、発生した問題と解決策などを明確にするために、パフォーマンステストレポートを作成します。そして、このパフォーマンステストの経験を要約してまとめます。具体的な性能試験レポートの作成については、「性能試験レポートテンプレート」を参照してください。
上記のすべての内容の中で、技術的な問題を除けば、パフォーマンステストをうまく行うのが最も難しいのは、ユーザーモデルの分析です。これは、ストレステストシナリオが実際の圧力を効果的にシミュレートできるかどうかを直接決定します。また、パフォーマンステストをより意味のあるものにするのは、実際の圧力のこのシミュレーションです。ある程度の性能テストが行われると、そのギャップがモデル確立に反映されると言える。
パフォーマンスの問題の分析、特定、調整に関しては、主に技術的な問題であり、さまざまな専門知識が必要です。データベース、オペレーティングシステム、ネットワーク、開発はすべて、資格のあるパフォーマンステスターに必要なスキルであり、これによってのみ、問題を多角的に検討し、分析することができます。
6. パフォーマンスツールの性能比較
現在市場で主流となっているパフォーマンスツールをベースに、環境ごとにテストツールを柔軟に選択できるよう、水平比較テストを実施しています。
6.1 パフォーマンスツールの比較結果
テストオブジェクト：Nginx Index.html (612Byte)、CPU：16コア / メモリ：16GB / ディスク：500GB
プレス：Ubuntu18.04、CPU：8コア / メモリ：8G / ディスク：500GB

ここに画像の説明を挿入

ここでは最も基本的な性能比較テストのみを実施しており、基本的なツール選定の判断のみを目的としています。
6.2 パフォーマンスツールの紹介
(1) wrk / wrk2
wrk は Http プロトコルのベンチマークツールであり、システムに付属する epoll、kqueue などの高性能 I/O 機構を条件付きで利用できます。単一マシンのマルチコア CPU のマルチスレッドとイベントモードにより、ターゲットマシンに大きな負荷を生成します。
PS: 実際、wrk は redis の ae 非同期イベント駆動フレームワークを再利用します。正確に言うと、ae イベント駆動フレームワークは redis によって発明されたものではありません。Tcl インタープリター jim から来ています。この小さく効率的なフレームワークは redis によって採用されています. 誰もがよく知っています。
利点:
軽量のパフォーマンステストツール、
簡単なインストール (Apache ab と比較)、
学習曲線は基本的にゼロ、数分で使用方法を習得できます、
システムに付属する高性能 I/O メカニズムに基づいて、 epoll、kqueue など、非同期イベント駆動フレームワークを使用すると、少数のスレッドで大量の同時実行性を絞り出すことができます。欠点:
wrk
は現在、単一マシンのストレステストのみをサポートしており、マルチマシンをサポートする可能性は低いです。 wrk の位置付けは、JMeter や LoadRunner などの専門的なテストツールを置き換えることを意図したものではありません。wrk が提供する機能は、バックエンド開発者が日々のインターフェイスのパフォーマンスを検証するのに使いやすいものです。
以前 LeTV では、テストアーキテクトが wrk2 に基づいて開発を主導し、分散をサポートしていましたが、開発コストは依然として若干高かったです。
基本的な使用法:
サブコマンドパラメータの説明:
使用方法: wrk <オプション> <テスト対象のHTTPサービスのURL>
オプション:
-c, --connections サーバーと確立および維持される TCP 接続の数
-d, --duration 圧力測定時間
-t, --threads 圧力測定に使用されるスレッドの数 (既製のコンテキスト切り替えを減らすため、公式推奨では、スレッド数は CPU コア数と同じです)

-s, --script      <S>  指定Lua脚本路径       
-H, --header      <H>  为每一个HTTP请求添加HTTP头      
    --latency          在压测结束后，打印延迟统计信息   
    --timeout     <T>  超时时间     
-v, --version          打印正在使用的wrk的详细版本信息

デジタルパラメータを表し、国際単位（1k、1M、1G）をサポートします。
時間パラメータを表し、時間単位（2s、2m、2h）をサポートします。
PS: スレッド数に関しては、設定が大きいほど優れているという意味ではありません。値が大きすぎるとスレッド切り替えが頻繁に発生し効果が低下しますので、一般的にはストレステスト機のCPUコア数の2～4倍に設定することを推奨します。

例

wrk -c400 -t24 -d30s --latency http://10.60.82.91/
レポート分析:
30 秒のテスト @ http://www.baidu.com を実行 (圧力テスト時間 30 秒)
12 スレッドと 400 接続 (合計 12テストスレッド、400 接続) (平均値) (標準偏差) (最大値) (プラスまたはマイナス 1 標準偏差の割合)スレッド統計平均標準偏差最大 +/- 標準偏差
(遅延)遅延 386.32 ミリ秒 380.75 ミリ秒 2.00 秒 86.66% ( 1 秒あたりのリクエスト数)リクエスト/秒 17.06 13.91 252.00 87.89%レイテンシー分布50% 218.31ms 75% 520.60ms 90% 955.08ms 99% 1.93s 30.06 秒で 4922 リクエスト、73.86MB 読み取り (30.06 秒以内に処理) 4922 リクエスト、73.86MB を消費ソケットエラー: 接続 0、読み取り 0、書き込み 0、タイムアウト 311 (発生したエラーの数)リクエスト/秒: 163.76 (QPS 163.76、つまり 1 秒あたりの平均処理リクエスト数は 163.76)転送/秒: 2.46MB (平均 2.46MB/秒)

30 秒のテストを実行 @ http://10.60.82.91/ (圧力テスト時間 30 秒)
32 スレッドおよび 400 接続 (合計 32 テストスレッド、400 接続)
(平均値) (標準偏差) (最大値) (プラスまたはマイナス)標準偏差の割合)
スレッド統計平均標準偏差最大 +/- 標準偏差
レイテンシ (遅延) 10.31ms 40.13ms 690.32ms 98.33% Req
/Sec (1 秒あたりのリクエスト数) 2.14k 482.15 6.36k 77.39%
レイテンシの分布
50% 5.11ms
75% 7.00ms
90% 9.65ms
99% 212.68ms

(2022092 リクエストが 30.10 秒で処理され、1.62 GB のトラフィックを消費) 2022092
リクエストが 30.10 秒で 1.62 GB 読み取り
リクエスト/秒: 67183.02 (QPS 67183.02、つまり、1 秒あたりに処理されるリクエストの平均数は 67183.02)
転送/秒: 55.03MB ( 1 秒あたりの平均トラフィックは 55.03MB)
(2) Jmeter
Jmeter は Java によって開発された、マルチスレッド同時実行モデルに基づいた圧力測定ツールであり、現在最も人気のあるオープンソースの圧力測定ツールです。以下の図に示すように、その動作原理は同様です。
ここに画像の説明を挿入

いわゆる仮想ユーザー (vuser) はスレッドに対応します。

単一スレッドでは、各リクエスト (クエリ) は同期的に呼び出され、次のリクエストは前のリクエストが完了するまで待ってから続行する必要があります。

リクエスト (クエリ) は 3 つの部分に分かれています。

send - ストレス側の受信側が完了するまで、ストレス側で送信を開始します。

wait - プレッシャーエンドの受信側が完了した時点から開始し、業務処理が終了するまで

recv - 圧力受信側は、圧力側がデータを受信するまでデータを返します。

同じスレッド内の 2 つの連続するリクエストの間には待ち時間という概念があります。つまり、図の空白部分です。

マルチスレッド同時実行モデルでは、スレッド数を継続的に増やすことによって、より大きな圧力を生成することは可能でしょうか?
答えは否定的です。
実際、プロセスは一度に 1 つのスレッドしか実行できません。いわゆる同時実行性とは、複数のタスクの同時実行性を実現するためにプロセス内のスレッドを継続的に切り替えることを指しますが、スレッドコンテキストの切り替えにはコストがかかりすぎます。逆に、スレッドの数が増えると、パフォーマンスが大幅に低下します。
ここに画像の説明を挿入

アプリケーションの観点から見ると、マルチスレッド同時実行モデルでは同時実行パラメーターの最大数を設定する必要があることがよくありますが、圧力テストのシナリオを継続的に増やす必要がある場合、そのようなツールでの対応は実際には非常に困難になります。
(3) Locust
Locust は、Python で開発された分散応力測定ツールで、近年中国で普及しています。Locust は Python のマルチスレッドではなく、コルーチン (gevent によって提供される) に基づいており、gevent はイベントループとして libev または libuv を使用します。
Locust の応答時間の歪みの問題:
Locust プレスの CPU がボトルネックに達すると、応答時間が大幅に歪みます。
たとえば、Locust の通常モードでは、8 つのプロセスと CPU ボトルネックがあり、90% の応答時間は 340 ミリ秒です。同時に、wrk によって得られた応答時間は 59.41 ミリ秒です。

ここに画像の説明を挿入

基本的な使用法の紹介:
デコレータータスクは圧力比を設定できます。
HttpUser の例:

locust import HttpUser から、タスク

class QuickstartUser(HttpUser):
# タスクは実行中のユーザーごとにグリーンレット (マイクロスレッド) を作成します
@task(1)
defdetail(self):
self.client.get(“http://10.60.82.91/”)

def on_start(self):
    pass

FastHttpUser の例

locust からのインポートタスク
locust.contrib.fasthttp からのインポート FastHttpUser

class QuickstartUser(FastHttpUser):
# タスクは実行中のユーザーごとにグリーンレット (マイクロスレッド) を作成します
@task(1)
defdetail(self):
self.client.get(“http://10.60.82.91/”)

def on_start(self):
    pass

開始と配布

-c 同時ユーザー数

-r 1 秒あたりに開始されたユーザーの数

-t 連続稼働時間

locust -fload_test.py --host=http://10.60.82.91 --no-web -c 10 -r 10 -t 1m

配布された

nohup locust -f locust_files/fast_http_user.py --master &
nohup locust -f locust_files/fast_http_user.py --worker --master-host=10.60.82.90 &
6.3 テストレコード
(1) wrk テストレコード
2 スレッド: -c1000 - t1 (少なくとも 2 つのスレッドのため) QPS: 35560.79
wrk -c1000 -t1 -d30s --latency http://10.60.82.91/
ここに画像の説明を挿入