新しいスクリプトAPIを使用してk6で定率リクエストを生成するにはどうすればよいですか?

こんにちは、Khabrovites。負荷テストコースの開始前夜に、もう1つの興味深い資料の翻訳を用意しました。






前書き



v0.27.0リリースでは、特定の要件に対応するために、新しい実行エンジンと多くの新しいエグゼキュータが提供されました。また、テスト対象システム(SUT)の負荷を調整およびシミュレートするためのさまざまなオプションを備えた新しいスクリプトAPIも含まれています。これは、悪名高い#1007プルリクエストに対する1年半の作業の結果です



一定の速度でクエリを生成するには、次を使用できます。constant-arrival-rateパフォーマー。このランナーは、指定された時間、固定頻度で繰り返しテストを実行します。これにより、k6は、テスト実行中にアクティブな仮想ユーザー(VU)の数を動的に変更して、単位時間あたりの指定された反復回数を達成できます。この記事では、このシナリオを使用して一定のレートでリクエストを生成する方法について説明します。



スクリプト構成オプションの基本



constant-arrival-rateexecutor を使用するスクリプトでテスト構成を説明するためにk6で使用される主要なパラメーターを見てみましょう



  • executor ():

    — k6. VU - — , , .
  • rate () timeUnit ( ):

    k6 rate timeUnit .



    :



    • rate: 1, timeUnit: '1s' « »
    • rate: 1, timeUnit: '1m' « »
    • rate: 90, timeUnit: '1m' « 90 », 1,5 /, 667 ,
    • rate: 50, timeUnit: '1s' « 50 », 50 (requests per second — RPS), , .. 20
  • duration ():

    , gracefulStop.
  • preAllocatedVUs:

    .
  • maxVUs:

    , .


これらのパラメーターが一緒になって、テスト構成オプションの一部あるスクリプト形成します。以下のコードスニペットはサンプルconstant-arrival-rateスクリプトです。



この構成には、constant_request_rateスクリプトのラベルとして使用される一意の識別子であるスクリプトがあります。このシナリオはconstant-arrival-rateエグゼキュータを使用し、1分で実行されます。毎秒(timeUnit)、1回の反復(rateが実行されます。事前にプロビジョニングされた仮想ユーザーのプールには20個のインスタンスが含まれ、要求と反復の数に応じて100に達する可能性があります。



テスト中に仮想ユーザーを初期化すると、CPUに負荷がかかるため、テスト結果が歪む可能性があることに注意してください。一般に、preAllocatedVU負荷テストを実行するのに十分なものがある方がよいでしょうしたがって、テスト内の要求の数とテストを実行する速度に応じて、より多くの仮想ユーザーを割り当てることを忘れないでください。



export let options = {
  scenarios: {
    constant_request_rate: {
      executor: 'constant-arrival-rate',
      rate: 1,
      timeUnit: '1s',
      duration: '1m',
      preAllocatedVUs: 20,
      maxVUs: 100,
    }
  }
};


一定の頻度でリクエストを生成する例 constant-arrival-rate



前のチュートリアル、我々は一定の要求率を計算する方法を示しました。スクリプトがどのように機能するかを念頭に置いて、もう一度見てみましょう。



テスト対象のシステムがエンドポイントで1秒あたり1000リクエストを処理することを期待しているとします。 100の仮想ユーザー(最大200)を事前に割り当てると、各仮想ユーザーは約5〜10の要求を送信できます(100〜200の仮想ユーザーに基づく)。各リクエストの完了に1秒以上かかる場合、予想よりも少ないリクエストを行うことになります(より多くdropped_iterations)。これは、テスト対象のシステムに対するパフォーマンスの問題または非現実的な期待の兆候です。この場合は、パフォーマンスの問題を修正してテストを再開するか、を調整して期待値を緩和する必要がありますtimeUnit



このシナリオでは、それぞれ予め割り当てられた仮想ユーザは、(10個の要求を行いますrateで割っpreAllocatedVU)。たとえば、応答を取得するのに1秒以上かかった場合や、テスト対象のシステムがタスクを完了するのに1秒以上かかった場合など、要求が1秒以内に受信されない場合、k6は、失われた要求を補うために仮想ユーザーの数を増やします。次のテストでは、出力には以下を参照することができますよう、およそ3万要求で30秒、1000秒あたりの要求と実行を生成しますhttp_reqsiterationsさらに、k6は200人の仮想ユーザーのうち148人しか使用しませんでした。



import http from 'k6/http';

export let options = {
    scenarios: {
        constant_request_rate: {
            executor: 'constant-arrival-rate',
            rate: 1000,
            timeUnit: '1s', // 1000   , ..1000  
            duration: '30s',
            preAllocatedVUs: 100, //      
            maxVUs: 200, //  preAllocatedVU ,    ,    
        }
    }
};

export default function () {
    http.get('http://test.k6.io/contacts.php');
}


このスクリプトを実行すると、次のようになります。



$ k6 run test.js


          /\      |‾‾|  /‾‾/  /‾/

     /\  /  \     |  |_/  /  / /

    /  \/    \    |      |  /  ‾‾\

   /          \   |  |‾\  \ | (_) |

  / __________ \  |__|  \__\ \___/ .io

  execution: local
     script: test.js
     output: -

  scenarios: (100.00%) 1 executors, 200 max VUs, 1m0s max duration (incl. graceful stop):
           * constant_request_rate: 1000.00 iterations/s for 30s (maxVUs: 100-200, gracefulStop: 30s)

running (0m30.2s), 000/148 VUs, 29111 complete and 0 interrupted iterations
constant_request_rate ✓ [======================================] 148/148 VUs  301000 iters/s

    data_received..............: 21 MB  686 kB/s
    data_sent..................: 2.6 MB 85 kB/s
    *dropped_iterations.........: 889    29.454563/s
    http_req_blocked...........: avg=597.53µs min=1.64µs  med=7.28µs   max=152.48ms p(90)=9.42µs   p(95)=10.78µs
    http_req_connecting........: avg=561.67µs min=0s      med=0s       max=148.39ms p(90)=0s       p(95)=0s
    http_req_duration..........: avg=107.69ms min=98.75ms med=106.82ms max=156.54ms p(90)=111.73ms p(95)=116.78ms
    http_req_receiving.........: avg=155.12µs min=21.1µs  med=105.52µs max=34.21ms  p(90)=147.69µs p(95)=190.29µs
    http_req_sending...........: avg=46.98µs  min=9.81µs  med=41.19µs  max=5.85ms   p(90)=53.33µs  p(95)=67.3µs
    http_req_tls_handshaking...: avg=0s       min=0s      med=0s       max=0s       p(90)=0s       p(95)=0s
    http_req_waiting...........: avg=107.49ms min=98.62ms med=106.62ms max=156.39ms p(90)=111.52ms p(95)=116.51ms
    *http_reqs..................: 29111  964.512705/s
    iteration_duration.........: avg=108.54ms min=99.1ms  med=107.08ms max=268.68ms p(90)=112.09ms p(95)=118.96ms
    *iterations.................: 29111  964.512705/s
    vus........................: 148    min=108 max=148
    vus_max....................: 148    min=108 max=148


テストスクリプトを作成するときは、次の点を考慮してください。



  1. k6 (), . , , maxRedirects: 0 . http , maxRedirects.
  2. . , , , , sleep().
  3. , , . preAllocatedVU / maxVU, , , , preAllocatedVU, maxVU .



    WARN[0005] Insufficient VUs, reached 100 active VUs and cannot initialize more  executor=constant-arrival-rate scenario=constant_request_rate


  4. , drop_iterations, iterations http_reqs . dropped_iterations , , . , , preAllocatedVU. , , , .
  5. , , . :



    WARN[0008] Request Failed
  6. スクリプトAPIは、duration、vus、およびstagesのグローバルな使用をサポートしていませんが、それらは引き続き使用できることに注意してください。これは、スクリプトと組み合わせて使用​​できないことも意味します。


結論



v0.27.0 リリースより前は、k6には一定のレートでリクエストを生成するための十分なサポートがありませんでした。したがって、スクリプトの各反復で要求を完了するのにかかる時間を計算することにより、JavaScriptで回避策を実装しましたv0.27.0では、これは不要になりました。



この記事では、k6が新しいスクリプトAPIを使用して一貫したリクエストレートを達成する方法について説明しました。constant-arrival-rateパフォーマー。このエグゼキュータはコードを簡素化し、1秒あたりの要求数を固定する手段を提供します。これは、同じ記事の以前のバージョンとは対照的です。以前のバージョンでは、式と定型的なJavaScriptコードを使用して仮想ユーザーの数、反復、および期間を計算することにより、実質的に同じ結果を達成する別の方法について説明しました。幸い、この新しいアプローチは意図したとおりに機能し、ハックを使用する必要がなくなりました。



この記事を楽しんでいただけたでしょうか。フィードバックをお待ちしております。







続きを読む



  • 炎のグラフィック:すべてのエンジンからの「火」



All Articles