Group_duration metric doesn't match with 'http_req_duration' metric value

Grafana k6 OSS Support
1

Hi,

I have run a load test to target single api within a group. At the end of test, when checking metrics in test summary report, noticed group_metric is not equal to http_req_duration eventhough there is only on api within group, no other code/logic wirtten other than this. PFB the report which we got after test completion. Observed one more point, group duraion is always high since which includes http_req_blocker time also. Please clarify is this behavior correct and shows the right value.

 data_received..................: 8.0 kB 133 B/s
 data_sent......................: 961 B  16 B/s
 group_duration.................: avg=4.79ms   p(50)=2.34ms  p(75)=2.4ms    p(90)=3.31ms   p(95)=15.92ms  p(99)=26.01ms  min=2.22ms  max=28.53ms 
 ✓ { group:::MonitorEngine }....: avg=4.79ms   p(50)=2.34ms  p(75)=2.4ms    p(90)=3.31ms   p(95)=15.92ms  p(99)=26.01ms  min=2.22ms  max=28.53ms 
 http_req_blocked...............: avg=2.28ms   p(50)=271ns   p(75)=320ns    p(90)=510ns    p(95)=12.56ms  p(99)=22.62ms  min=240ns   max=25.13ms 
 http_req_connecting............: avg=178.44µs p(50)=0s      p(75)=0s       p(90)=0s       p(95)=981.42µs p(99)=1.76ms   min=0s      max=1.96ms  
✓ http_req_duration..............: avg=2.4ms    p(50)=2.25ms  p(75)=2.3ms    p(90)=3.2ms    p(95)=3.24ms   p(99)=3.27ms   min=2.1ms   max=3.28ms  
   { expected_response:true }...: avg=2.4ms    p(50)=2.25ms  p(75)=2.3ms    p(90)=3.2ms    p(95)=3.24ms   p(99)=3.27ms   min=2.1ms   max=3.28ms  
 http_req_failed................: 0.00%  ✓ 0        ✗ 11 
 http_req_receiving.............: avg=49.03µs  p(50)=46.57µs p(75)=54.4µs   p(90)=58.1µs   p(95)=60µs     p(99)=61.52µs  min=38.89µs max=61.9µs  
 http_req_sending...............: avg=110.41µs p(50)=98.16µs p(75)=123.48µs p(90)=136.31µs p(95)=174.68µs p(99)=205.37µs min=72.78µs max=213.04µs
 http_req_tls_handshaking.......: avg=644.47µs p(50)=0s      p(75)=0s       p(90)=0s       p(95)=3.54ms   p(99)=6.38ms   min=0s      max=7.08ms  
 http_req_waiting...............: avg=2.24ms   p(50)=2.11ms  p(75)=2.15ms   p(90)=3.01ms   p(95)=3.02ms   p(99)=3.03ms   min=1.98ms  max=3.03ms  
 http_reqs......................: 11     0.183323/s
 iteration_duration.............: avg=4.84ms   p(50)=2.38ms  p(75)=2.45ms   p(90)=3.36ms   p(95)=16ms     p(99)=26.11ms  min=2.26ms  max=28.64ms 
 iterations.....................: 11     0.183323/s
 vus............................: 0      min=0      max=0
 vus_max........................: 1      min=1      max=1
3

Hi @prmmuthu :wave:

Thanks for sharing the details of your test report.

Some context

The behavior you’re seeing with group_duration being higher than http_req_duration is expected and can likely be explained by understanding how k6 measures these metrics:

  • http_req_duration: measures the time taken to complete the HTTP request, from sending the request to receiving the final byte of the response. This includes the time spent in the http_req_sending, http_req_waiting, and http_req_receiving phases.
  • group_duration: measures the total time taken to execute everything within the group. This includes the time spent on the HTTP request(s) but also accounts for any other operations or code within that group, including the setup, teardown, and possible delays like http_req_blocked (time spent waiting for a TCP connection) or other time spent outside the actual request.

Why the group_duration is likely higher

Even though you only have a single API call within the group, group_duration includes all the time spent in the group, which might involve more than just the HTTP request. Specifically:

  • http_req_blocked time: This is included in group_duration but not in http_req_duration. If there’s significant time spent in DNS resolution, connecting, or waiting for a free socket, it will increase the group_duration.
  • runtime impact of the group: Any time taken by the k6 runtime to enter and exit the group context can also contribute to the group_duration. Keep in mind that groups are actual javascript functions that k6 needs to execute and contain some logic.

Conclusion

Thus, I believe the behavior you’re observing is likely indeed correct.

If you think there’s more to it, could you please share a simple script demonstrating what you’re trying to achieve so we have more context? I’ve also noticed you use a relatively low number of iterations, which could lead to the gap between group_duration and your requests to be statistically higher, if you run a couple of order of magnitude more iterations, do you still observe a significant gap?

:bowing_man: