Hi @SteOH
Welcome back 
Regarding the timing issue, it’s important to note that the constant-arrival-rate executor does not guarantee a request is sent exactly every timeUnit (10 seconds in your case), but rather attempts to send requests at a constant rate over the duration of the test.
The actual timing between requests may vary due to various factors, such as server response times, network delays, and the performance of the local machine running the test. It’s normal to see some variation in the request intervals, and this variation can be greater when there is high variability in the response times of the system being tested.
What you should see is an iterations/s that matches your configuration, in this case, close to 0.10 iter/s.
I ran a similar example based on our example in the docs and what I get is 0.116042/s iterations:
execution: local
script: const-arr-rate.js
output: -
scenarios: (100.00%) 1 scenario, 100 max VUs, 1m30s max duration (incl. graceful stop):
* contacts: 0.10 iterations/s for 1m0s (maxVUs: 10-100, gracefulStop: 30s)
running (1m00.3s), 000/010 VUs, 7 complete and 0 interrupted iterations
contacts ✓ [======================================] 000/010 VUs 1m0s 0.10 iters/s
data_received..................: 43 kB 717 B/s
data_sent......................: 3.2 kB 52 B/s
http_req_blocked...............: avg=228.41ms min=216.17ms med=223.38ms max=257.74ms p(90)=246.58ms p(95)=252.16ms
http_req_connecting............: avg=110.32ms min=103.44ms med=106.03ms max=128.47ms p(90)=122.88ms p(95)=125.67ms
http_req_duration..............: avg=112.28ms min=105.35ms med=106.26ms max=133.47ms p(90)=126.68ms p(95)=130.07ms
{ expected_response:true }...: avg=112.28ms min=105.35ms med=106.26ms max=133.47ms p(90)=126.68ms p(95)=130.07ms
http_req_failed................: 0.00% ✓ 0 ✗ 7
http_req_receiving.............: avg=144.14µs min=83µs med=145µs max=201µs p(90)=193.2µs p(95)=197.1µs
http_req_sending...............: avg=81.28µs min=44µs med=100µs max=106µs p(90)=105.4µs p(95)=105.7µs
http_req_tls_handshaking.......: avg=117.72ms min=109.85ms med=117.14ms max=129.09ms p(90)=125.37ms p(95)=127.23ms
http_req_waiting...............: avg=112.06ms min=105.06ms med=106.08ms max=133.21ms p(90)=126.42ms p(95)=129.82ms
http_reqs......................: 7 0.116042/s
iteration_duration.............: avg=341.15ms min=322.86ms med=331.09ms max=391.67ms p(90)=373.78ms p(95)=382.72ms
iterations.....................: 7 0.116042/s
vus............................: 10 min=10 max=10
vus_max........................: 10 min=10 max=10
From what I understand you need to ensure that a request is sent exactly every 10 seconds. Is that correct? Can you provide a bit more context for the need? Do you need the test to run for only 1 minute?
You could try using the ramping-arrival-rate executor with a rate of 1 request every 10 seconds. This executor ramps up the arrival rate gradually, which can help smooth out any variations in request timing.
export const options = {
discardResponseBodies: true,
scenarios: {
contacts: {
executor: 'ramping-arrival-rate',
startRate: 1,
timeUnit: '10s',
preAllocatedVUs: 10,
maxVUs: 100,
stages: [
{ target: 1, duration: '10s' },
{ target: 1, duration: '10s' },
{ target: 1, duration: '10s' },
{ target: 1, duration: '10s' },
{ target: 1, duration: '10s' },
{ target: 1, duration: '10s' },
],
},
},
};
Regarding your question about the http_reqs metric, this metric counts the number of HTTP requests sent during the test, regardless of their timing. It’s not related to the start time of any particular request. The http_req_duration metric measures the duration of each HTTP request, which can help you understand how long the system takes to respond to each request.
On a side note, I would recommend to increase the preAllocatedVUs to make sure the test can run without having to allocate more mid-test. As this can affect the metrics as well. You can read more about this in the docs: Arrival-rate VU allocation
I hope this helps.
Cheers!
