Mismatch request count in alb Vs http_reqs

Here is my stages and the summary report. My question is, using this stage, I’m hitting an endpoint behind ALB, I see the total request count as 4K in the ALB metric. However, if you see in the summary report below. I see the’ http_reqs’ as 96333. What number I should consider for total number of hits. 96333 or 4K? Is ther any reason, the http_reqs is mismatching with the ALB request count?

export let options = {
    stages: [
        { duration: "10m", target: 500 },
        { duration: "10m" , target: 800 },
        { duration: "20m", target: 1500 }
    ]
};

Summary report

scenarios: (100.00%) 1 scenario, 1500 max VUs, 40m30s max duration (incl. graceful stop):
           * default: Up to 1500 looping VUs for 40m0s over 3 stages (gracefulRampDown: 30s, gracefulStop: 30s)


     ✓ status is 200

     checks.........................: 100.00% ✓ 96333     ✗ 0
     data_received..................: 140 MB  58 kB/s
     data_sent......................: 5.6 MB  2.3 kB/s
     http_req_blocked...............: avg=3.92ms   min=197ns   med=344ns   max=308.08ms p(90)=485ns   p(95)=564ns
     http_req_connecting............: avg=1.28ms   min=0s      med=0s      max=133.41ms p(90)=0s      p(95)=0s
     http_req_duration..............: avg=20.07s   min=20.06s  med=20.06s  max=20.31s   p(90)=20.08s  p(95)=20.08s
       { expected_response:true }...: avg=20.07s   min=20.06s  med=20.06s  max=20.31s   p(90)=20.08s  p(95)=20.08s
     http_req_failed................: 0.00%   ✓ 0         ✗ 96333
     http_req_receiving.............: avg=335.75µs min=18.81µs med=39.91µs max=132.88ms p(90)=52.88µs p(95)=57.76µs
     http_req_sending...............: avg=35.91µs  min=10.98µs med=22.14µs max=238.43ms p(90)=34.3µs  p(95)=38.69µs
     http_req_tls_handshaking.......: avg=2.61ms   min=0s      med=0s      max=213.93ms p(90)=0s      p(95)=0s
     http_req_waiting...............: avg=20.07s   min=20.06s  med=20.06s  max=20.29s   p(90)=20.08s  p(95)=20.08s
     http_reqs......................: 96333   39.805794/s
     iteration_duration.............: avg=20.07s   min=20.06s  med=20.06s  max=20.42s   p(90)=20.08s  p(95)=20.08s
     iterations.....................: 96333   39.805794/s
     vus............................: 23      min=1       max=1499
     vus_max........................: 1500    min=1500    max=1500


running (40m20.1s), 0000/1500 VUs, 96333 complete and 0 interrupted iterations
default ✓ [======================================] 0000/1500 VUs  40m0s

Hi @ampk6

Welcome to the community forum :wave:

Without more context, not knowing anything about your ALB or the k6 script, I believe the number of requests sent by k6 is indeed 96333. The difference can be due to anything, from a cache before the ALB returning requests to ALB counting open connections and not reused ones.

If having more context about your system (which we don’t have) does not help, can you share the (sanitized) script you are using? We can try to help you figure out this, though it’s probably easier when you have access to your SUT (system under test) platform and know the architecture and we might not be able to pinpoint the cause.

Cheers!