Не понимая метрики к6

Question

Не понимая метрики к6

Я проверил нагрузку на моем сервере с k6, и у меня есть некоторые сомнения по поводу результатов, которые я получил.

          /\      |‾‾|  /‾‾/  /‾/   
     /\  /  \     |  |_/  /  / /    
    /  \/    \    |      |  /  ‾‾\  
   /          \   |  |‾\  \ | (_) | 
  / __________ \  |__|  \__\ \___/ .io

    init [----------------------------------------------------------] runner
    init [----------------------------------------------------------] options
    init [----------------------------------------------------------] executor
    init [----------------------------------------------------------]   engine
    init [----------------------------------------------------------]   collector
    init [----------------------------------------------------------]   server
  execution: local
     output: -
     script: ./src/benchmark/script.js

    duration: 20s, iterations: -
         vus: 1,   max: 1

    init [----------------------------------------------------------] starting
    ✓ status was 200

    checks.....................: 100.00% ✓ 477 ✗ 0  
    data_received..............: 9.5 GB  477 MB/s
    data_sent..................: 55 kB   2.8 kB/s
    http_req_blocked...........: avg=3.69µs  min=1.88µs  med=2.87µs  max=282.62µs p(90)=4.08µs  p(95)=4.33µs 
    http_req_connecting........: avg=485ns   min=0s      med=0s      max=232.2µs  p(90)=0s      p(95)=0s     
    http_req_duration..........: avg=18.87ms min=18.18ms med=18.86ms max=27.83ms  p(90)=19.35ms p(95)=19.44ms
    http_req_receiving.........: avg=36.37µs min=13.59µs med=23.64µs max=786.38µs p(90)=60.69µs p(95)=80.54µs
    http_req_sending...........: avg=39.7µs  min=13.82µs med=20.18µs max=3.16ms   p(90)=34.81µs p(95)=35.58µs
    http_req_tls_handshaking...: avg=0s      min=0s      med=0s      max=0s       p(90)=0s      p(95)=0s     
    http_req_waiting...........: avg=18.8ms  min=18.15ms med=18.82ms max=27.77ms  p(90)=19.26ms p(95)=19.31ms
    http_reqs..................: 478     23.899925/s
    iteration_duration.........: avg=41.83ms min=40.07ms med=41.51ms max=112.2ms  p(90)=42.18ms p(95)=42.66ms
    iterations.................: 477     23.849925/s
    vus........................: 1       min=1 max=1
    vus_max....................: 1       min=1 max=1

Соображения:

Размер ответа составляет 20 МБ.
Я настроил тест только с 1 виртуальным пользователем.
Клиент (экземпляр EC5 m5.4xlarge) отправляет эти запросы на сервер (еще один экземпляр EC2 m5.4xlarge).
Оба сервера находятся в одной зоне доступности.
Я пропинговал свой сервер, и были получены следующие результаты:

150 packets transmitted, 150 received, 0% packet loss, time 152557ms
rtt min/avg/max/mdev = 0.162/0.220/0.293/0.031 ms

150 packets transmitted, 150 received, 0% packet loss, time 152569ms
rtt min/avg/max/mdev = 0.164/0.217/0.262/0.028 ms

150 packets transmitted, 150 received, 0% packet loss, time 152574ms
rtt min/avg/max/mdev = 0.162/0.218/0.426/0.037 ms

150 packets transmitted, 150 received, 0% packet loss, time 152567ms
rtt min/avg/max/mdev = 0.173/0.227/0.266/0.028 ms

Метрики, которые меня интересуют, следующие:

http_req_receiving.........: avg = 36.37µs
http_req_sending...........: avg = 39,7 мкс
http_req_waiting...........: avg=18,8 мс
http_req_duration..........: avg = 18.87ms
iteration_duration.........: avg = 41,83 мс

Если в документации к6 сказано, что:

http_req_sending: время, потраченное на отправку данных на удаленный хост.
http_req_receiving: время, потраченное на получение данных ответа от удаленного хоста.

Среднее значение ping составляло 0,220 мс (220 мкс), а значения http_req_receiving и http_req_sending ниже, чем среднее значение ping.

Проблема в том, что я не знаю, как связать пинг с http_req_receiving и http_req_sending.

Я думаю, что http_req_sending - это время, необходимое для перемещения запроса из точки A в точку B, а http_req_receiving - это время, необходимое для перемещения запроса из точки C в точку D. Я прав?

Проверьте следующее изображение: https://i.ibb.co/m6JJDK1/Screen-Shot-2019-02-02-at-11-23-00.png

РЕДАКТИРОВАТЬ: Я проверил с локон, который... предложил. Вот результаты некоторых кудрей:

Для ответа, который содержит 20 миллионов символов (20 МБ):

Коннект: 0.000241 TTFB: 0.028431 Общее время: 0.061042

Коннект: 0.000254 TTFB: 0.018196 Общее время: 0.050792

Коннект: 0.000236 TTFB: 0.023359 Общее время: 0.056002

Коннект: 0,001865 TTFB: 0,019826 Общее время: 0,053621

Коннект: 0.000238 TTFB: 0.018920 Общее время: 0.051638

Коннект: 0.000240 TTFB: 0.018243 Общее время: 0.050905

Коннект: 0.000226 TTFB: 0.019197 Общее время: 0.051828

Коннект: 0.000226 TTFB: 0.018293 Общее время: 0.050941

Коннект: 0.000239 TTFB: 0.019187 Общее время: 0.051830

Для ответа, который содержит 1 символ (1 байт):

Соединиться: 0.000241 TTFB: 0.000539 Общее время: 0.000562

Соединиться: 0.000238 TTFB: 0.000532 Общее время: 0.000553

Коннект: 0.000237 TTFB: 0.000525 Общее время: 0.000547

Соединиться: 0.000257 TTFB: 0.000524 Общее время: 0.000548

Коннект: 0.000231 TTFB: 0.000499 Общее время: 0.000519

Соединить: 0.000238 TTFB: 0.000512 Общее время: 0.000537

Коннект: 0.000232 TTFB: 0.000511 Общее время: 0.000534

0

amazon-ec2 ping load-testing metrics

Источник

John 02 фев '19 в 15:41

1 ответ

Другие вопросы по тегам amazon-ec2 ping load-testing metrics

Михаил Стойков 04 фев '19 в 07:01 2019-02-04 07:01 · Answer 1 · 2019-02-04 07:01

Как уже было упомянуто, метрики, которые предоставляет k6, (в основном) для HTTP как протокола, и поэтому связать его с ping может быть немного... сложно:).

В принципе ping измеряет, как долго одиночный пакет проходит от точки A до B и от C до D вместе взятых. Он не измеряет ни один из путей в одиночку. Это то, что обычно называют туда и обратно. Также важно отметить, что ping не использует tcp, который добавляет дополнительные ускорения / замедления, когда у нас есть многочастотные циклы, как в случае HTTP-запросов.

С другой стороны, k6 измеряет, сколько разных частей целого HTTP-запроса (множества таких циклов) проходит. Особенно http_req_sending измеряет все время с момента, когда k6 установил соединение с хостом, до момента, когда он написал запрос. С уважением http_req_receiving все время с момента, когда k6 получил первый байт обратно, до момента, когда он получил последний байт ответа. Ни один из них на самом деле не измеряет циклические переходы - в случае отправки базовой ОС может на самом деле не отправлять данные в течение некоторого времени, и мы можем получить весь ответ от ОС очень быстро.

Для ваших конкретных номеров: http_req_sending выглядит довольно хорошо - он маленький, потому что в основном мы записываем несколько байтов в соединение, а ОС говорит, что отправит данные. Интересное ваше http_req_receiving что также очень мало (последовательно), так как я ожидаю, что это займет немного больше времени, с ответом такого размера. Либо какая-то очень тяжелая буферизация происходит где-то до k6, либо вы используете старую версию k6 (до v0.23.1), где у нас были некоторые ошибки при использовании HTTP2. Или мы не исправили все ошибки в этих случаях:(.

Вы можете проверить с curl чтобы увидеть, как велико будет время отклика

curl -o /dev/null -H 'Cache-Control: no-cache' -s -w "Connect: %{time_connect} TTFB: %{time_starttransfer} Total time: %{time_total} \n"

скрипт скручивания от https://gist.github.com/sandeepraju/1f5fbdbdd89551ba7925abe2645f92b5

источник: я разработчик k6;)