Expose an on_hatch event? And/or hatch number (e.g. we just hatched user number X) as well

[daluu]

The API docs mention a hatch_complete event hook. That's useful but I don't always care to know about all users started (could monitor from other metrics in the test environment).

What could be useful to me is a way to track a hatch event, to do something on hatch.

On a related note, it would also be helpful to know what each hatched user's number is (when they hatched as in I'm user number X). Helpful for data association to users based on ID/number. You don't always want to do it randomly, sometimes yes.

So, could we get an on_hatch event hook?

What would be nice also would be if we could get whatever locust uses to track the current hatch count (or equivalent) available as an attribute to read from. Something like JMeter's thread number/count property where in code you can figure out which user/thread number you are for whatever load logic you are trying to do. (e.g. self.locust.hatch_number)

[aldenpeterson-wf]

Can't you just put this logic into the locust itself in the on_start method?

[daluu]

I guess I could, but it would be nice to have a convenience implementation provided so less logic for the test writer. Similar to why there's a self.client that points to self.locust.client, I suppose you could have let the test writer write out the full reference to the client to avoid a convenience method.

It's more hassle to have the test writer deal with concurrency for a global counter associating each hatched user. I'd assume locust itself keeps track of that somewhere (as can be seen in UI for test progress), why not provide it for the test writer to make use of?

[begoldsm]

This is right along the lines of what I am looking for as well. I want to send a value to my server based on which locust "user" number the current instance is. @aldenpeterson-wf you mention that I can do this in my on_start methods, but I am not clear on how I can do this. How would that method know which user it is, especially in a distributed test with master/slave nodes?

[begoldsm]

@aldenpeterson-wf ping on this, is there an example of how we could denote different user numbers in each spawned user in a distributed test?

[aldenpeterson-wf]

Hrm, I see what you are saying - you want effectively a "locust id" of sorts that you can use within the context of the on_start.

I wonder if something like that would be worth adding or finding a way to expose. I know at least one person who would find it beneficial (cc @thomaslevans-wf)

[thomaslevans-wf]

+1 for an on_hatch event hook!

[begoldsm]

@aldenpeterson-wf yes yes! That would be great, especially so that we can do interesting distribution logic and determine which "users" might be having interesting experiences, or, in the case of doing login/authentication validation, ensuring that we are using a true unique user to login for each locust "user", and knowing which user is associated with which locust slave.

[trevorrjohn]

Is there any progress on the hatch_number? This is definitely something that I feel is necessary to run more complicated load tests.

[braveswang]

Any progress on the hatch_number or other method?

[cgoldberg]

progress would be shown by an update to this issue. so... no.

[cyberw]

Workarounds for getting the number of currently running locusts exist, so a workaround is possible. Closing because low prio and no activity.

[daluu]

@cyberw, @aldenpeterson-wf, so if we're saying a workaround is good enough for this, can we get some example workarounds to elaborate how to effectively do this? That would really help, rather than leave it to the users to figure out.

[cyberw]

You can get the current number of users by calling runners.locust_runner.user_count

Maybe I should have left this open, but I dont want to give the impression that we're working on it or something. I guess there's little harm in keeping it open if there is an interest in it.

[heyman]

On a related note, it would also be helpful to know what each hatched user's number is (when they hatched as in I'm user number X).

This is unlikely to be built into Locust, because it would be hard to do when running Locust distributed. Slave nodes operate independently of each other, and when new nodes connect the master rebalances the simulated users across the nodes.

You can get the current number of users by calling runners.locust_runner.user_count

Please note that when running this in a slave node, this will only report the number of simulated users running in that node. Slave nodes do not know of the other running nodes.