Wie generiere ich Anfragen mit konstanter Rate in k6 mit der neuen Skript-API?

Hallo Khabrovites. Im Vorfeld des Beginns des Lasttestkurses haben wir für Sie eine Übersetzung eines weiteren interessanten Materials vorbereitet.






Einführung



Die Version v0.27.0 brachte uns eine neue Ausführungs-Engine und viele neue Ausführende, um Ihre spezifischen Anforderungen zu erfüllen. Es enthält auch eine neue Skript- API mit vielen verschiedenen Optionen zum Optimieren und Simulieren der SUT-Last (Test System). Dies ist das Ergebnis von anderthalb Jahren Arbeit an der berüchtigten Pull-Anfrage Nr. 1007 .



Um Abfragen mit einer konstanten Rate zu generieren, können wir verwendenconstant-arrival-rateKünstler. Dieser Läufer führt den Test mit Iterationen mit einer festen Frequenz für die angegebene Zeit aus. Dadurch kann k6 die Anzahl der aktiven virtuellen Benutzer (VUs) während der Testausführung dynamisch ändern, um die angegebene Anzahl von Iterationen pro Zeiteinheit zu erreichen. In diesem Artikel werde ich erklären, wie dieses Szenario verwendet wird, um Anforderungen mit einer konstanten Rate zu generieren.



Grundlagen der Skriptkonfigurationsoptionen



Werfen wir einen Blick auf die wichtigsten Parameter, die in k6 verwendet werden, um eine Testkonfiguration in einem Skript zu beschreiben, das einen constant-arrival-rateExecutor verwendet:



  • 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:

    , .


Zusammen bilden diese Parameter ein Skript , das Teil der Testkonfigurationsoptionen ist . Das folgende Codefragment ist ein Beispielskript constant-arrival-rate.



In dieser Konfiguration haben wir ein constant_request_rateSkript, bei dem es sich um eine eindeutige Kennung handelt, die als Bezeichnung für das Skript verwendet wird. Dieses Szenario verwendet einen constant-arrival-rateExecutor und wird in 1 Minute ausgeführt. Jede Sekunde ( timeUnit) wird 1 Iteration ( rate) ausgeführt . Der Pool vorab bereitgestellter virtueller Benutzer enthält 20 Instanzen und kann je nach Anzahl der Anforderungen und Iterationen 100 erreichen.



Beachten Sie, dass das Initialisieren virtueller Benutzer während eines Tests CPU-intensiv sein und daher die Testergebnisse verzerren kann. Im Allgemeinen ist es besser, preAllocatedVUgenug zu haben, um den Belastungstest durchzuführen. Vergessen Sie daher nicht, abhängig von der Anzahl der Anforderungen in Ihrem Test und der Rate, mit der Sie den Test ausführen möchten, mehr virtuelle Benutzer zuzuweisen.



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


Ein Beispiel für das Generieren von Anforderungen mit einer konstanten Häufigkeit mit constant-arrival-rate



Im vorherigen Tutorial haben wir gezeigt, wie die konstante Anforderungsrate berechnet wird. Schauen wir uns das noch einmal an und denken Sie daran, wie Skripte funktionieren:



Angenommen, Sie erwarten, dass Ihr zu testendes System 1000 Anforderungen pro Sekunde an einem Endpunkt verarbeitet. Durch die Vorbelegung von 100 virtuellen Benutzern (maximal 200) kann jeder virtuelle Benutzer ungefähr 5 bis 10 Anforderungen senden (basierend auf 100 bis 200 virtuellen Benutzern). Wenn jede Anfrage länger als 1 Sekunde dauert, stellen Sie am Ende weniger Anfragen als erwartet (mehrdropped_iterations), was ein Zeichen für Leistungsprobleme oder unrealistische Erwartungen an Ihr zu testendes System ist. In diesem Fall sollten Sie die Leistungsprobleme beheben und den Test neu starten oder Ihre Erwartungen durch Anpassen moderieren timeUnit.



In diesem Szenario stellt jeder vorab bereitgestellte virtuelle Benutzer 10 Anforderungen ( rateteilbar durch)preAllocatedVU). Wenn beispielsweise innerhalb von 1 Sekunde keine Anforderungen eingehen, dauerte es länger als 1 Sekunde, bis eine Antwort eingeht, oder Ihr zu testendes System benötigte mehr als 1 Sekunde, um die Aufgabe abzuschließen. K6 erhöht die Anzahl der virtuellen Benutzer, um die fehlenden Anforderungen zu kompensieren. Der folgende Test generiert 1000 Anforderungen pro Sekunde und wird 30 Sekunden lang ausgeführt, was ungefähr 30.000 Anforderungen entspricht, wie Sie in der folgenden Ausgabe sehen können: http_reqsund iterations. Darüber hinaus verwendete k6 nur 148 von 200 virtuellen Benutzern.



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');
}


Das Ergebnis der Ausführung dieses Skripts lautet wie folgt:



$ 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


Berücksichtigen Sie beim Schreiben eines Testskripts die folgenden Punkte:



  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. Denken Sie daran, dass die Skript-API die globale Verwendung von Dauer, Vus und Stufen nicht unterstützt, obwohl sie weiterhin verwendet werden können. Dies bedeutet auch, dass Sie sie nicht in Verbindung mit Skripten verwenden können.


Fazit



Vor der Veröffentlichung von Version 0.27.0 hatte k6 keine ausreichende Unterstützung, um Anforderungen mit einer konstanten Rate zu generieren. Aus diesem Grund haben wir eine Problemumgehung in JavaScript implementiert und die Zeit berechnet, die erforderlich ist, um Anforderungen für jede Iteration des Skripts abzuschließen. Mit v0.27.0 ist dies nicht mehr erforderlich.



In diesem Artikel habe ich erläutert, wie k6 mit der neuen Skript-API eine konsistente Anforderungsrate erzielen kannconstant-arrival-rateKünstler. Dieser Executor vereinfacht den Code und bietet die Möglichkeit, eine feste Anzahl von Anforderungen pro Sekunde zu erreichen. Dies steht im Gegensatz zu einer früheren Version desselben Artikels, in der ich eine andere Methode beschrieben habe, um nahezu dieselben Ergebnisse zu erzielen, indem die Anzahl der virtuellen Benutzer, Iterationen und die Dauer mithilfe einer Formel und etwas JavaScript-Code berechnet wurden. Glücklicherweise funktioniert dieser neue Ansatz wie beabsichtigt und wir müssen keine Hacks mehr verwenden.



Ich hoffe, Ihnen hat das Lesen dieses Artikels gefallen. Ich würde mich über Ihr Feedback freuen.







Weiterlesen






All Articles