In our efforts to triumph in a smart city project, I came across Locust– a load testing framework that made my work more smooth.
Introduction to Locust
Locust is a small, modern open-source Python tool for load testing web pages, APIs, etc. It is incredibly hackable, straightforward to use, and completely event-based. It avoids using callbacks tho and instead uses the gevent library to generate clients as light-weight processes, allowing for more expressive and readable tests.
The documentation is excellent and being open-source, we can always peek under the hood to understand what is going on. Also, it should be noted that it can be run in distributed mode, controlled from either web-based UI or CLI, where you can monitor results in real-time.
Recently, we have been competing (and have won) in a tender for a smart city project. The project in question had several high-load test scenarios. Scenarios were combinations of different protocols, payload sizes, payload types and sending frequency. A scenario could range from dumping tens of gigabytes of data instantaneously or sending thousands of requests per second, or a combination of both.
Given that we were already performing load tests internally, this presented an excellent opportunity to improve our tooling.
Given that we were already performing load tests internally, this presented an excellent opportunity to improve our tooling. We evaluated a couple of tools, but we found only two which had all we needed, Gatling and Locust. While Gatling is a great tool, ease of use, hackability and just general awesomeness of Locust prevailed, and we never looked back. It was effortless to generate new test scenarios and deploy across hundreds of nodes.
Simple use case
Out of the box, Locust supports HTTP client. I will just quickly demonstrate a simple test, shamelessly taken from Locust official documentation:
As you can see, without even knowing anything about the Locust API, you could already reasonably guess what the test does. The test tries to open two URLs, log in the user before that and log the user out upon finishing.
To start the test run:
To start a distributed test, start master process with:
and then start an arbitrary number of slave processes:
For more examples, I would suggest taking a look at project documentation and seeing for yourself how things fit together.
How we use it
In our case, we have either used existing or created our Locust classes. We then leveraged docker images and Kubernetes to manage automation controlling the Locust tests configuration by passing environment variables.
The only real problem we encountered was gracefully stopping individual tasks after a fixed number of requests without breaking the whole test suite. This is something we plan to revisit soon and find the correct way to handle it.
It is worth mentioning that while testing, you can use standard Python modules, so Locus is perfect for Python- centric developers. Currently, we are looking for an expert in this field, so do not also hesitate to check the vacancy.
I would highly recommend trying out Locust. Even for small personal projects, you can easily set up end to end tests. For large systems, it is also relatively easy to integrate into CI pipelines and can be used for different types of tests.
Tests written within Locust are easy to read and understandable. This alone is worth hours and hours of our development time. I had fun writing tests, which is already saying quite a lot!
December 18, 2019
Continuosly building, testing, releasing and monitoring t-matix mobile apps