Incorrect number of requests in summary
See original GitHub issueHi! I have the following configuration file:
config:
http:
pool: 2
timeout: 240
target: 'http://localhost:8080'
phases:
- duration: 10
arrivalRate: 10
scenarios:
- flow:
- log: "New user"
- post:
url: '/v1/links'
json:
foo: 'bar'
I expected to have 100 requests in the summary, but I got a different number:
How is this possible?
Issue Analytics
- State:
- Created 2 years ago
- Reactions:2
- Comments:7 (3 by maintainers)
Top Results From Across the Web
How to Fix 429 Too Many Requests Error - Kinsta
The HTTP 429 error is returned when too many requests are made to a page within a short period of time. Find out...
Read more >Common errors | Content API for Shopping - Google Developers
Summary, Issued a request targeting an account to which the authenticated user doesn't have access. Common causes, Error in the target ...
Read more >10 Error Status Codes When Building APIs For The First Time ...
Your API request may return error status codes such as “401 Unauthorized” or “502 Bad Gateway” when you begin using your API for...
Read more >COMMON ERRORS IN KRONOS AND HOW TO FIX THEM
Employees must follow the proper procedure to request pay for overtime hours ... The Hours Summary screen provides a snapshot of the employee's...
Read more >Common error messages in Data Loader - Salesforce Help
Error: ID value of incorrect record type. Cause: Record type needs to be entered with ID, not name. Resolution: Review your file's values...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Working on versions:
So, I believe that you have multiple tickets open for the same type of issue. I think the issue boils down to: the final summary is not a complete aggregate of all other summary slices. Here is another example that I run on my local machine, not distributed.:
I expect 30 requests to be created, and I believe they are created, but the final summary is not complete.
Here is an example output:
You can see there are no failure codes, all requests passed. In slice 1, I created 21 vusers, which makes sense because ~ 7 seconds went by. In slice 2, I create the final 9 vusers. So 30 vusers are runing. If you go back and count, it looks like 30 vusers also end up completed.
So I think that the issue is how you calculate the final summary.
An important thing to note is I would expect the http.max to be 225 not 211 and the number of http.request to be over 100.
Is it possible that failures are happening and that could be why it is incorrect?
thanks for the extra info @spinlud! you’re right, requests that timeout are still meant to be included in the report (as
ETIMEOUT
errors)