Hello,
I’m doing a load test of 100 users, but not really sure what duration here really means or how to properly provide it’s value.
export let options = {
vus: 100, // virtual users
duration: "3s",
httpDebug: 'full',
};
Does it mean each user will take 3 seconds max to run it’s test?
or something else?
Hello,
The duration option is documented here. As the docs suggest, duration determines the total length of the test, i.e. VUs will continuously call the default function in your script until the duration value is exceeded.
A 3s test duration is quite short, so you will likely find that each VU only completes a handful of iterations before k6 instructs them to stop running.
If what you are looking to do is have your VUs reach a certain throughput, you might want to use the Constant Arrival Rate executor which caters for the definition of a target rate.
So if the duration is 3 seconds and virtual users is 100, then the test function will be called whatever it can call it in a matter of 3 seconds, is that right?
If so, then how can I provide a value that fits these 100 users?
should I omit duration and use iterations instead?
My goal is to see how my homepage load to 100 users.
If you are wanting to ensure that your site can handle 100 concurrent users, then you will probably want to design a test where you ramp up to 100 concurrent VUs over a period of time, and then maintain the load at that level for another period of time. This would be achieved using the Ramping VUs executor.
As this type of executor option is quite common in load testing, there’s a shortcut to define it which doesn’t involve creating a full-blown scenario. To utilize the shortcut, all you need to do is specify stages within your options.
Here’s an example:
export const options = {
stages = [
{ duration: '10m', target: 100 },
{ duration: '10m', target: 100 },
],
}
With the above, your test would ramp-up to 100 VUs from 0 over 10min, and then keep the load at 100 for a further 10 minutes.
Important to note is that concurrent VUs don’t necessarily translate directly to concurrent real users. A VU is executing code and will do so as fast as it can, whereas a real user would navigate, spend some time absorbing what’s on the page, and then a while later navigate to another page, and so on.
That is why adding sleep statements is important: they allow you to introduce “think time” that slows down the speed of a VU so that it more closely mimics the actions of a real user. These sleep statements are typically added between requests or between group functions, in situations where there are multiple HTTP requests that take place as a result of a single user-initiated action.
Take a look at this repo if you want to see an example set of scripts that employ the above:
You’ll note that the sleep statements in main.js also randomly select a duration from within a range (2-5sec). This further increases the realism of the test (some users will naturally navigate around faster than others). What the range should be will completely depend on how long you yourself think real users would spend on each page of your site.
I’ll also point out that the definition of “concurrent users” is not particularly well-defined. If I remember correctly, Google Analytics will consider a user to still be “active” until it sees 2min of inactivity. Worth bearing in mind!
Hope that helps.
Thanks a lot for your thorough answer. I really now have a better idea about load testing.
I will implement this with all your points in mind. I appreciate your time.
Hi @omar ,
Did it work for you?
I am trying to run it for 600 users and a duration of 10m. It fails everytime. I can increase the duration though but what’s the best way to carry out the load testing?