テストのパフォーマンスに影響する可能性がある次のスクリプト構成項目を検討することをお勧めします。
実際のHTTPメソッドの使用が「高速」のメソッドよりも重要である理由を説明したいと思います。 受信したデータのチェックを使用し、値を取得するために正規表現を作成する必要性に触れます。
実際のデータサイズで応答を取得する
私の意見では、少なくともWebシステムの最終テストでは、ブラウザーが送信するリクエストを使用する必要があります。 GETリクエストだった場合、シミュレーションするだけで、たとえばHEADに置き換えないでください。 これらのメソッドの主な違いは、GETは応答のコンテンツを受信しますが、HEADは受信しないことです。 たとえば、写真、CSS、フォントなどから不要なデータを取得する必要があるように思えますが、実践が示すように、それらはそれほど重要ではありません。
同じテストリソースの2種類のクエリを比較する
ヘッド
ゲット
写真は、GET要求がHEAD要求よりも何倍も時間がかかることを示しています。 したがって、サーバーはこのリクエストのデータをより長く提供し、次のサービスを提供できませんでした。 ユーザーが1人の場合、この差はそれほど大きくないように見えますが、1,000人の仮想ユーザーを使用する場合、サーバーは各ユーザーの処理に時間を費やしません。
たとえば、Webサーバーは、100の同時接続しか処理できないように構成されています。 その結果、最初の100個が接続され、少なくとも3秒間機能することがわかります。 同時に、残りの900個すべてが接続を待機します。 最初の100人の誰かが終了するとすぐに、次の人にリソースを提供します。 つまり、この例の1000番目のユーザーは、約27秒後にのみ、指定された要求で作業を開始できます。 HEADメソッドを使用した場合、1000番目のユーザーは2秒でシステムにアクセスできます。 （これらの計算は非常に大雑把です）
その結果、「正しい」メソッドを使用してサーバーにアクセスすると、実際の負荷がどのように表示されるかがわかります。
写真で使用されている例は完全に合成されており、クエリ実行時間の観点から見やすくなっています。 それほど多くのリクエストがないかもしれません。 ただし、応答が100〜200キロバイトで、5,000人のユーザーを使用している場合でも、Webサーバーの動作が大幅に低下することがわかります。
受信したデータを確認する
多くの人は、受信したデータをチェックすることは負荷テストではなく、機能テストであると言うでしょう。そして、あなたはいくつかの点で正しいでしょう。 実際には、Webシステムの機能部分が高負荷の下で正しく動作しなくなることがわかりました。 たとえば、Webアプリケーションは、高負荷下で着信データを適切に処理しない場合があります。
Webシステムが要求の成功を報告し、200 OKの応答を送信する状況に遭遇しました。 しかし、リクエストの本文は空でした。システムを詳細に調査した結果、これが計画された応答であることがわかりました。 つまり、リクエストの成功は、レスポンス内のコンテンツの存在によってのみ判断できます。
高負荷時のシステムの正しい動作を検証する唯一の方法は、応答のステータスだけでなく、受信したデータを制御することであることがわかりました。
現在、Webシステム（AJAX、WebSocket、Flash、Javaなど）との動的な作業のための技術の集中的な開発により、同じリクエストで異なるコンテンツを受け取ることができます。 また、応答テキストが正しいことを確認する必要があります。
「正規」正規表現の構築
多くのユーティリティでは、受信したデータの正確性を検証するために、正規表現を使用して負荷テストを実行する必要があります。 私たちは皆それが何であるかを知っていますが、「正規の」正規表現とは何ですか。 これは、元の値を見つけるのにできるだけ時間がかからない式です。
インターネットには、特定の正規表現やエンジンが使用されるパフォーマンスの低さに関する多くの例と記事があります。 彼らは、怠zy、貪欲、超貪欲な量指定子が何であるかを説明します。 グルーピングと交替を使用する理由とタイミング。 正規表現エンジンの速度を上げるために指定する方法。 私はそれが重要で興味深い人にとって、彼らは情報を見つけることができると思います。
それらを正しく構築する必要がある理由を示したいと思います。 録音中に遅延が発生した特定のクエリのシーケンスを見てみましょう。
写真では、遅延は緑の矢印で示されています。 スクリプトを実行するとき、ユーティリティはリクエスト間の遅延をシミュレートし、それにより「実際の」ユーザー負荷を保証する必要があります。
前の段落から、受信したデータを制御する必要があることがわかりました。 これは正規表現で行います。 その結果、一部のクエリでは、式を作成してチェックを開始します。
実行されるチェックには、データの検索に時間がかかるはずです。 その結果、次のようなものが得られます
赤い矢印は、正規表現に費やされる時間を示しています。
その結果、スクリプトの合計実行時間は、1人のユーザーがそれを実行した場合の方法について既に少しずれていることがわかります。 各仮想ユーザーがこのようなチェックを行う必要があることを考慮し、1台のコンピューターでこれらの1,000個を実行している場合、それらの処理時間は数倍になります。 各仮想ユーザーは、コンピューティング用のオペレーティングシステムリソースをキャプチャします。 したがって、リソースは一部のユーザーが占有している間、他のユーザーはそれらにアクセスできません。
正規表現が正確であるほど、それを処理する時間が短くなり、多数の仮想ユーザーがいるシステムに実際の負荷がかかります。
もちろん、多くの場合、正規表現の使用、さらには「正しい」オプションは必要ありません。 ただし、テストを仮想ユーザーにとってより現実的な条件に近づけたい場合は、サービス機能の速度を忘れないでください。
おわりに
負荷テストの結果の歪みに影響する可能性のある3つの可能なオプションを調べました。 もちろん、説明されているすべての状況が、サーバー接続時間、サーバー応答時間、および受信する他の特性などのパラメーターに影響するわけではありません。
しかし、ほとんどの場合、1つまたは別のシナリオを実行する実際のユーザーの数、サーバーが応答する速度、および各ユーザーがこのシナリオに費やす時間に関心があります。 ただし、これらのパラメーターでは、検査される項目を調整できます。
サーバーのリクエストに対する応答時間は数ミリ秒です。 大量のデータを受信して処理する場合、スクリプト全体の実行時間は数分かかる場合があり、このようなテストのお客様には受け入れられない場合があります。
更新： 記事を完了する