Advice on how to test multiple methods for multiple kinds of user?

I’ve been given some specs that look something like:

Role 1 performs actions A, B, C at 10k times a day
Role 2 performs actions D, E, F at 15k-30k times a day

The network runs any combination of A, B, C, D, E, F in any order throughout the day.

Though I am running multiple requests, I am thinking I should be using the RPS method as opposed to the VU method? Because this is just arbitrarily hitting API endpoints, not some sequential UI flow. Role 1 could be doing AB, while Role 2 is doing D, and while another Role 2 is doing EF, all at the same time for all I know.

I think the first thing I do is break the “a day” into minutes, so let’s say Role 1 performs at 10k a day => ~7 per minute.

Now I’d like to see how things run as close to “at the same time” for the roles as possible, so how the network would react if everyone does everything they tend to do throughout the day (or is that a bad idea?). I assume this means I should probably http.batch([A, B, C]) the requests for a role? By the way, groups don’t run parallel, do they?

Now how would I actually handle the different roles? If I’d like to see how they stress the network when they are all hitting it? Should Role 1 and Role 2 in different scripts and I try to run them in parallel via bash & or docker-compose, or should they fit in one script and I can assign different VUs/RPS to them to somehow split them up?


Hi @kite, sorry for the late reply :frowning:
I would really recommend to find out what the distribution between the 2 roles is… and between the three actions … in particular, I would examine with the idea that there are really 6 actions and they are with the following distribution (for the purposes of the example :wink: )

A - 10%
B - 20%
C - 30%
D - 20%
E - 5%
F - 15%

As proposed in How to distribute VU's across different scenarios with k6 and particular this comment you can do

export default function() {
	let userDistro = Math.floor(Math.random() * 100);

	switch (true) {
		case (userDistro <= 10):
			// action A
		case (userDistro > 10 && userDistro <= 30):
			// action B
		case (userDistro > 30 && userDistro <= 60):
			// action C
		case (userDistro > 60 && userDistro <= 80):
			// action D
		case (userDistro > 80 && userDistro <= 85):
			// action E
		case (userDistro > 85 && userDistro <= 100):
			// action F
			// This really shouldn't be happing

And with 10000 iterations over 100 vus I get:

   A....................: 1063  1874.221718/s
    B....................: 1993  3513.945327/s
    C....................: 2949  5199.510673/s
    D....................: 2037  3591.523649/s
    E....................: 510   899.20327/s
    F....................: 1448  2553.032029/s

which seems pretty close to what we want :slight_smile:

If you run the above script with the actual actions and enough VUs (more than 6 for example :wink: ) you will get different VUs running a different action in parallel :wink:
You can read more about how VUs work in k6 here