Understanding rate in constant-arrival-rate executor

I’m using constant-arrival-rate executor and running 1170 req/sec.

{
  executor: 'constant-arrival-rate',
  duration: '1800s',
  rate: 1170,
  timeUnit: '1s',
  preAllocatedVUs: 50,
  maxVUs: 3500
}

If you see the summary below, the http_reqs shows as “104944 169.239844/s”.
But being, I’m using constant-arrival-rate, I expect, the http_reqs should be near to 1170 (that I’ve set in the above config)

execution: local
     script: test.js
     output: -

  scenarios: (100.00%) 1 scenario, 3500 max VUs, 10m30s max duration (incl. graceful stop):
           * testCall: 1170.00 iterations/s for 10m0s (maxVUs: 50-3500, gracefulStop: 30s)

WARN[0011] Insufficient VUs, reached 3500 active VUs and cannot initialize more  executor=constant-arrival-rate scenario=testCall
INFO[0620] [k6-reporter v2.3.0] Generating HTML summary report  source=console
     ✓ status is 200

     █ setup

     checks.........................: 100.00% ✓ 104944     ✗ 0
     data_received..................: 161 MB  259 kB/s
     data_sent......................: 7.1 MB  11 kB/s
     dropped_iterations.............: 597056  962.853179/s
     http_req_blocked...............: avg=6.58ms  min=141ns   med=285ns   max=288.55ms p(90)=357ns   p(95)=405ns
     http_req_connecting............: avg=2.18ms  min=0s      med=0s      max=118.22ms p(90)=0s      p(95)=0s
     http_req_duration..............: avg=20.21s  min=20.06s  med=20.11s  max=24.4s    p(90)=20.24s  p(95)=20.8s
       { expected_response:true }...: avg=20.21s  min=20.06s  med=20.11s  max=24.4s    p(90)=20.24s  p(95)=20.8s
     http_req_failed................: 0.00%   ✓ 0          ✗ 104944
     http_req_receiving.............: avg=34.89µs min=12.57µs med=29.35µs max=396.95ms p(90)=38.43µs p(95)=41.53µs
     http_req_sending...............: avg=23.09µs min=10.88µs med=21.01µs max=783.62µs p(90)=27.6µs  p(95)=33.58µs
     http_req_tls_handshaking.......: avg=4.37ms  min=0s      med=0s      max=170.95ms p(90)=0s      p(95)=0s
     http_req_waiting...............: avg=20.21s  min=20.06s  med=20.11s  max=24.4s    p(90)=20.24s  p(95)=20.8s
     http_reqs......................: 104944  169.239844/s
     iteration_duration.............: avg=20.22s  min=11.45µs med=20.11s  max=24.6s    p(90)=20.24s  p(95)=20.86s
     iterations.....................: 104944  169.239844/s
     vus............................: 35      min=35       max=3500
     vus_max........................: 3500    min=359      max=3500


running (10m20.1s), 0000/3500 VUs, 104944 complete and 0 interrupted iterations
testCall ✓ [======================================] 0000/3500 VUs  10m0s  1170.00 iters/s

Also, in addition to this:

1. I’ve set 3500 as VUs & and rps as 1170, so is that every VU will invoke 1170/sec (i.e. 3500x1170 = 4,095,000 request). I’m pretty much sure this should not be case as summary has different numbers (i.e. 104944) and in my ALB request count for 10minutes period(See image)?
2. How does VUs works in this executor and with respect to constant requests?
3. Also, in the summary, the min of vus_max is 359. Is that only 359 VUs were executed through out this activity?
   Is there any documentation avaiable to understand in better way?

rate: 1170, timeUnit: '1s' means 1170 requests per 1 second (distributed across all VUs).

k6 will inject new VUs to achieve this rate (up to maxVUs). You need to tune this number depending on how fast your server responds under load. More VUs require more local memory to execute.

In your case, 3500 is too low:

> WARN[0011] Insufficient VUs, reached 3500 active VUs and cannot initialize more executor=constant-arrival-rate scenario=testCall

Which means your VUs are maxed out/saturated.

Another interesting metric:

     http_req_duration..............: avg=20.21s  min=20.06s  med=20.11s  max=24.4s    p(90)=20.24s  p(95)=20.8s

Your average request duration is 20 seconds. That means you would need at least 1170 times 20 (23400) VUs to sustain 1170 rps.