add 99th percentile to stdout metrics

[ghost]

On sites that serve traffic at thousands of requests per second, we may need a higher percentile than 95. I think at least 99. Maybe also higher. 99 plus some more 9s?

[antekresic]

@aidylewis can you check if the merged PR #462 satisfies this issue?

[ghost]

Thanks for the enhancement. Is this in master?

$ go get -u github.com/loadimpact/k6
$ k6 version
k6 v0.18.2

[robingustafsson]

@aidylewis Yes, and will be in a new release before the end of the week.

[ghost]

I've done a go get, built the source and moved the k6 binary into $GOPATH/bin. I am not seeing p99.

[robingustafsson]

p99 is not included by default, but you can now configure the summary output like so:
k6 run --summary-trend-stats "min,avg,med,max,p(95),p(99),p(99.99)" script.js

[ghost]

Very nice. Speak soon.

$ k6 run --summary-trend-stats "min,avg,med,max,p(95),p(99),p(99.99)" http_2.js

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

  execution: local
     output: -
     script: http_2.js

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

    done [==========================================================] 1 / 1

    ✓ protocol is HTTP/2
    ✓ status is 200

    checks.....................: 100.00% ✓ 2   ✗ 0
    data_received..............: 278 kB  497 kB/s
    data_sent..................: 1.4 kB  2.5 kB/s
    http_req_blocked...........: min=196.75ms avg=196.75ms med=196.75ms max=196.75ms p(95)=196.75ms p(99)=196.75ms p(99.99)=196.75ms
    http_req_connecting........: min=15.08ms  avg=15.08ms  med=15.08ms  max=15.08ms  p(95)=15.08ms  p(99)=15.08ms  p(99.99)=15.08ms
    http_req_duration..........: min=355.96ms avg=355.96ms med=355.96ms max=355.96ms p(95)=355.96ms p(99)=355.96ms p(99.99)=355.96ms
    http_req_receiving.........: min=310.7ms  avg=310.7ms  med=310.7ms  max=310.7ms  p(95)=310.7ms  p(99)=310.7ms  p(99.99)=310.7ms
    http_req_sending...........: min=2.3ms    avg=2.3ms    med=2.3ms    max=2.3ms    p(95)=2.3ms    p(99)=2.3ms    p(99.99)=2.3ms
    http_req_tls_handshaking...: min=162.12ms avg=162.12ms med=162.12ms max=162.12ms p(95)=162.12ms p(99)=162.12ms p(99.99)=162.12ms
    http_req_waiting...........: min=42.95ms  avg=42.95ms  med=42.95ms  max=42.95ms  p(95)=42.95ms  p(99)=42.95ms  p(99.99)=42.95ms
    http_reqs..................: 1       1.788671/s
    iteration_duration.........: min=559.83ms avg=559.83ms med=559.83ms max=559.83ms p(95)=559.83ms p(99)=559.83ms p(99.99)=559.83ms
    iterations.................: 1       1.788671/s
    vus........................: 1       min=1 max=1
    vus_max....................: 1       min=1 max=1

[V3ckt0r]

Hey @robingustafsson, you mention that the 99th percentile is not included by default in the output. However I just wanted to clarify, are the 99th percentile metrics not gather by the core unless the output flag is provided? Or is it collected just not displayed unless the flag is provided?
Thanks

[robingustafsson]

@V3ckt0r The core collects raw non-aggregated data points (for "trend" metrics like response times). The percentiles are calculated from the raw data points, so what's printed to stdout is just a calculated summary.

[ghost]

@V3ckt0r Can we not store the raw metrics in InfluxDB and use the percentile function in InfluxQL?