guesses ➤ sometimes we can reason about capacity by performing canaries, then applying mathematics ➤ Even so, it’s good to know when the breaking point is of a single service ➤ and be able to scale out accordingly ➤ Being able to scientifically prove limits and responsiveness is very important!
in the language we primarily develop in (python) ➤ Also wanted to leverage existing client code ➤ Even use auth details from Vault ➤ Want to test non-http services (rabbitmq, memcached, kafka, etc.) ➤ Be able to easily spin up a swarm on EC2 ➤ A dashboard GUI of some kind would be a little nice too
to benchmark mcrouter + N memcached boxes ➤ Tests are written completely in python ➤ Very Flexible… can do anything you can do in python ➤ Can do multi-step tests ➤ e.g. login, set and get this value, etc. ➤ Can run in a distributed environment with many workers
Locust will spawn one instance of the class for each user being simulated ➤ `task_set` - points to a TaskSet class that defines the behavior of the user ➤ min_wait and max_wait - the minimum and maximum time a user may wait between requests, randomized
http ➤ self.client - HttpSession implementation of requests.Session ➤ The source code of this is a GREAT place to read if you want to extend Locust to support non-http protocols
do with event handling ➤ Very crucial if you make your own custom Locust class to define startup / shutdown behaviors ➤ One interesting way to use them: building a custom metric collection mechanism.