Background: In our load testing environment, we have been utilizing k6 to perform comprehensive tests on our web applications. One critical aspect of our tests involves the browser tests to be enabled.
Challenge: When browser testing is disabled, we obtain essential metrics such as http_reqs, http_req_blocked, and http_req_receiving etc , which play a pivotal role in our performance evaluations. However, when browser testing is enabled, these metrics are replaced with browser-centric ones like browser_web_vital_lcp, browser_web_vital_fid, etc.
Objective: Our goal is to bridge this gap and find a way to integrate the http_reqs and related metrics alongside the browser-specific metrics when browser testing is enabled.
Questions:
- Is there a recommended approach to obtain
http_reqs, http_req_blocked, and http_req_receiving metrics alongside browser-specific metrics during k6 load tests with browser testing enabled?
- Has anyone successfully managed to combine browser-centric metrics with traditional HTTP request/response metrics in k6? If so, could you share your insights or methodologies?
- Are there any specific configurations or plugins that can be employed to achieve a unified set of metrics in k6 when browser testing is enabled?
Please feel free to share your experiences, suggestions, or any resources that might be helpful in tackling this challenge. Your contributions will greatly assist us in optimizing our load testing process for more comprehensive performance assessments. Thank you!
Hello @sumansourav,
Welcome aboard!
Can you help me understand a few things to fine-tune my response to your needs?
- What’s the reasoning behind your desire for
http_reqs when browser-specific metrics are available?
- Is there any reason the browser-specific HTTP metrics don’t align with your requirements?
- What drives you to amalgamate the browser-centric metrics with the classic HTTP ones?
From what I gather, you’re working with k6 tests and possibly analyzing their results or even feeding them into different software. The metric names shift when the browser tests are activated. Usually, all the HTTP metrics should be displayed alongside browser metrics.
I’m keen to understand why this poses a challenge for you. Mind shedding some light on it? Could you also show us a script snippet where this behavior occurs?
Appreciate it!
1 Like
Hi @sumansourav
You can get browser/web vital metrics combined with classic http metrics by combining a browser scenario with a standard protocol scenario (hybrid load testing). This example has both test types running in parallel and here are the unified results. The idea here is to keep the browser load limited due to the overhead on the load generator.
/\ |‾‾| /‾‾/ /‾‾/
/\ / \ | |/ / / /
/ \/ \ | ( / ‾‾\
/ \ | |\ \ | (‾) |
/ __________ \ |__| \__\ \_____/ .io
execution: local
script: C:\k6\hybrid.js
output: -
scenarios: (100.00%) 2 scenarios, 11 max VUs, 1m30s max duration (incl. graceful stop):
* browser: 1 looping VUs for 1m0s (exec: browserTest, gracefulStop: 30s)
* news: 10 looping VUs for 1m0s (exec: news, gracefulStop: 30s)
✓ status is 200
✓ checkbox is checked
browser_data_received..........: 205 kB 3.3 kB/s
browser_data_sent..............: 17 kB 279 B/s
browser_http_req_duration......: avg=40.09ms min=12.31ms med=44.51ms max=102.61ms p(90)=67.49ms p(95)=75.52ms
browser_http_req_failed........: 50.00% ✓ 25 ✗ 25
browser_web_vital_cls..........: avg=0 min=0 med=0 max=0 p(90)=0 p(95)=0
browser_web_vital_fcp..........: avg=553.29ms min=504.39ms med=551ms max=645.79ms p(90)=587.29ms p(95)=613.86ms
browser_web_vital_fid..........: avg=668µs min=399.99µs med=699.99µs max=1ms p(90)=800µs p(95)=879.99µs
browser_web_vital_inp..........: avg=32ms min=32ms med=32ms max=32ms p(90)=32ms p(95)=32ms
browser_web_vital_lcp..........: avg=553.29ms min=504.39ms med=551ms max=645.79ms p(90)=587.29ms p(95)=613.86ms
browser_web_vital_ttfb.........: avg=59.72ms min=43.5ms med=55.69ms max=102.3ms p(90)=75.85ms p(95)=96.85ms
checks.........................: 100.00% ✓ 25016 ✗ 0
data_received..................: 40 MB 642 kB/s
data_sent......................: 2.7 MB 45 kB/s
http_req_blocked...............: avg=454.46µs min=0s med=0s max=132.56ms p(90)=0s p(95)=0s
http_req_connecting............: avg=175.47µs min=0s med=0s max=42.23ms p(90)=0s p(95)=0s
http_req_duration..............: avg=22.71ms min=509.29µs med=16.52ms max=5.09s p(90)=33.27ms p(95)=54.42ms
{ expected_response:true }...: avg=22.71ms min=509.29µs med=16.52ms max=5.09s p(90)=33.27ms p(95)=54.42ms
http_req_failed................: 0.00% ✓ 0 ✗ 24991
http_req_receiving.............: avg=407.23µs min=0s med=0s max=61.21ms p(90)=772.8µs p(95)=2.22ms
http_req_sending...............: avg=29.97µs min=0s med=0s max=45.86ms p(90)=0s p(95)=0s
http_req_tls_handshaking.......: avg=248.21µs min=0s med=0s max=63.03ms p(90)=0s p(95)=0s
http_req_waiting...............: avg=22.27ms min=509.29µs med=16.17ms max=5.09s p(90)=32.8ms p(95)=53.7ms
http_reqs......................: 24991 406.452243/s
iteration_duration.............: avg=25.55ms min=509.8µs med=17.15ms max=5.09s p(90)=36.54ms p(95)=58.04ms
iterations.....................: 25016 406.858841/s
vus............................: 1 min=1 max=11
vus_max........................: 11 min=11 max=11
running (1m01.5s), 00/11 VUs, 25016 complete and 0 interrupted iterations
browser ✓ [======================================] 1 VUs 1m0s
news ✓ [======================================] 10 VUs 1m0s
1 Like
