Knowledge Planet の一部の学生は、パフォーマンスの問題に遭遇しました。問題は次のとおりです: 静的リソースは Nginx に配置され、リソースのサイズは約 10 M です。Nginx は docker でデプロイされます。圧力テスト中に、静的リソースの読み込みが非常に遅かったです。トラブルシューティングと分析の方法をグループで尋ねます。
これは非常に一般的なパフォーマンスの問題であり、通常は帯域幅やメモリなどのリソースが不足していることが原因で発生します。もちろん、パフォーマンスの問題の分析は、推測や経験に基づいて恣意的に導き出すことはできず、工学的思考で分析および確認し、最終的に最適化および検証する必要があります。
この記事では、私自身の経験と組み合わせて、実際のパフォーマンスの問題分析とトラブルシューティングの方法について説明します。
パフォーマンス問題分析チェーン
以下のマインド マップを見てみましょう。これは、私が仕事でパフォーマンスの問題に遭遇したときによく使用する分析方法であり、分析チェーンと呼んでいます。
上の図に示すように、分析チェーンは次のようになります (データは参考用です)。
-
問題のパフォーマンスを観察します。テスト環境、サービス構成 2C4G、同時実行数が 20 ～ 200 増加、同時実行数が 100 に到達、RT が急上昇、20% の間違ったリクエスト。
-
証拠のリンクを見つける: 全帯域幅、100% のメモリ使用量、多数のリクエスト タイムアウト、エラー レポート、異常なスタックなど、問題がある場所を見つけます。
-
問題の原因を分析します。なぜこのような問題が発生するのでしょうか? 一般的な分析はトップダウン、つまりスクリプト、データ、シナリオ、構成、コード、システム アーキテクチャです。
-
パフォーマンス最適化の検証: 監視とログを使用して、考えられる原因を消去法で迅速に特定し (豊富な経験が必要)、推測をデバッグして検証します。問題がない場合は、問題を修正して再テストして検証し、監視とログを観察して問題が解決されたことを確認します。
パフォーマンス分析の実践事例
記事冒頭の学生の質問を例に挙げると、それをどのように分析すればよいでしょうか?
まず第一に、このストレス テスト シナリオでは静的ファイルが読み込まれます。一般的な静的リソースには主に画像または一部のフロントエンド ページが含まれます。次に、リソース サイズが 10+M の場合、この静的リソースは画像または短いビデオ; 問題の説明で Nginx は docker でデプロイされ、静的リソースは Nginx にマウントされるため、Nginx のストレージ リソースを考慮する必要があると記載されていますが、なぜですか?
ストレス テスト中は、通常、さまざまなユーザーからの複数のリクエストが URL にアクセスするためにシミュレートされます。リクエストごとに異なるイメージが返され、同時実行性が比較的高い場合、サービスの IO プレッシャーは比較的高くなります。ストレス テスト クラスターとテスト対象サービス間のネットワーク帯域幅リソースについても考慮する必要がありますが、帯域幅が 100M しかない場合、実際の伝送効率の理論上のピーク値は 12.5M/S にすぎません。 。このシナリオでは、同時実行性が高くても、実際の TPS が 1 以下になる可能性があるという問題が発生します。
パフォーマンス テストを実行するときに多くの受験者がよく犯す間違いは、実際のビジネス シナリオとテスト対象サービスの構成とネットワーク帯域幅を無視し、大量の同時リクエストを無分別にシミュレートすることです。これは科学的でも合理的でもありません。実際には、特定のビジネス シナリオとテスト対象のサービスの構成を考慮して、電子商取引ビジネスの一般的な seckill シナリオなどのスクリプトを設計する必要があり、この時点で高い同時実行性をシミュレートできます。
上記の問題では、考慮すべき点が 2 つあります。1 つ目は、比較的大きな静的リソースを Nginx にマウントすることです。より合理的な技術的解決策は、静的リソースまたは大きなファイルを使用し、写真などの特別なファイル ストレージ サービスを使用することです。 CNDに保存されます。2 番目の点も見落とされがちですが、パフォーマンスを向上させるには、送信前にファイルを圧縮し、表示層で解凍するのが最善です。もちろん、これには高解像度の要件がないことが前提です。イメージのために。
インターネット上の多くの記事では、ストレス テスト ツールの使用方法、テスト データの準備方法、同時実行スキルのシミュレーション方法が紹介されていますが、私の考えでは、これらは単なる手段にすぎません。パフォーマンステストで最も重要な部分はパフォーマンス要件の分析段階であり、分析段階では、テスト対象のビジネスシナリオの特性を可能な限り考慮する必要があり、システムアーキテクチャとその背後にある技術実装スキームが合理的であるかどうか、潜在的なパフォーマンスのボトルネックがあるかどうか。圧力試験は検証の手段にすぎず、検証の目的ではありません。
近年、テストの左シフトが叫ばれていますが、品質組み込みや品質アクセス管理だけでなく、実は要件段階の分析・評価やボトムアップ戦略の策定の方が重要です。
最後に:以下の完全なソフトウェア テスト ビデオ チュートリアルが整理されてアップロードされており、必要な友人は自分で入手できます[100% 無料を保証]
ソフトウェアテストの面接ドキュメント
私たちは高給の仕事を見つけるために勉強しなければなりません。次の面接の質問は、アリ、テンセント、バイトなどの一流インターネット企業からの最新の面接資料であり、一部のバイトの上司が権威ある回答をしています。このセットを完了してください。面接資料は次のとおりです。誰もが満足のいく仕事を見つけることができると信じています。
