Story by
Igor Crnković

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.

Backstory

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:

Copy to Clipboard

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:

Copy to Clipboard

To start a distributed test, start master process with:

Copy to Clipboard

and then start an arbitrary number of slave processes:

Copy to Clipboard

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.

Conclusion

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!