Back in 2011, Carl Bystrom and Jonatan Heyman were developing Battlelog, a companion app to the Battlefield 3 release. Players would be able to sign into Battlelog to chat with friends and launch games with their squad.
Anticipating millions of players wanting to play Battlefield 3 on launch day, Jonatan and his team knew they would have to load test Battlelog to prevent a crash. They looked into the existing load testing options, but nothing was able to generate a realistic load and simulate the actual players.
And so Locust came to be the way many open source projects do — its creators were looking for a better solution to a challenge they were facing. As we celebrate 13 years, about 60 million downloads, and over 25,000 stars on GitHub, I caught up with Jonatan to reflect on where the project came from and where it’s headed.
Looking back: Why Locust was needed
At the time, websites and ecommerce stores weren’t as complex and personalized as they are today. With a webshop for example, users don’t typically interact with one another, and most of the load testing tools catered to this use case. Battlelog was effectively a social network, and load testing those interactions required more flexibility.
While a lot of companies might start with a small amount of traffic and expect to increase gradually, the Battlelog team knew a lot of players would be trying to access the app at the same time — each being a crucial first impression for the new app.
JMeter was commonly used for load testing at the time, but was limited by operating system threads, requiring too many machines to generate sufficient load. It also relied on defining tests within the UI, which was “kind of clunky because we needed to have users sign into this system, have a list of their friends and communicate with them,” Jonatan says. “The load was much more dynamic than just hitting individual pages.”
The team also considered Tsung, but the way to define load tests didn’t work well for their use case. Apache Bench “worked really well if you want to hit a single URL end point with as much traffic as possible, but wasn’t flexible enough to create a realistic load for our needs.”
Unable to find a suitable tool for their unique use case, Carl made a proof of concept of a new load testing tool, using Python and gevent. Jonatan recalls, “I think he hacked it together in a weekend to see if it was possible.”
While Carl and Jonatan worked on the project in their free time, the goal was always to use it for work, and fortunately their employer ESN was happy for them to continue work on it during working hours and keep it open source. “We were already using a lot of open source tools, so I guess they wanted to give something back,” says Jonatan.
Locust 1.0
I discovered Locust in 2018 when it relatively mature, but had yet to receive its 1.0 release. I made my first contributions to the project the following year, and in 2020, Jonatan and I collaborated on simplifying the codebase and created the first ‘stable’ release.
Because I was using Locust in my day-to-day work as a consultant in Load/Performance Testing, I was personally motivated to improve the project, and became the most active maintainer, accepting pull requests and supporting users. Since then, we’ve shipped over 100 releases, adding features and gently modernizing things.
But until recently making big changes and improvements wasn’t really possible because I still had a full time job using Locust. All I had time for was fixing bugs and implementing smaller changes. That wouldn’t change until 2024, when I started Locust Technologies with the help of OCV.
We’ve been busy building a lot of features around load generation infrastructure and reporting, and while Locust Cloud is a commercial offering, as part of our work we uncover and fix small bugs when running really big load tests trying new scenarios — all of which benefits the open source project.
With open source, we can do anything (but not everything)
From proof of concept, to Locust 1.0, to distributed load generation, two web UI revamps, and growing the ranks of maintainers, the project has evolved a lot over the last 13 years.
As always, we have to strike a balance between what individuals want and what’s best for the project. “My philosophy has always been that if you add something to an open source project, then the project should make sure that this is now supported,” says Jonatan. “So I’ve always felt that if it can live outside the project then it should.” The maintainers can’t be experts in every use case for a contribution, and it’s not realistic to expect the contributor to foresee all the possible consequences of their pull requests, or assume responsibility for it forever.
One thing that has really helped us with evaluating code contributions is an extensive set of automated tests. We’ve caught a lot of weird bugs that way — someone comes in to fix one small thing, possibly only reading one source code file, and in testing we’ll discover that one small change impacts something else in another part of the codebase. It’s especially important to test changes from open source contributors, because they’re less likely to be familiar with the whole codebase than full-time developers.
Looking ahead: browser-based testing, AsyncIO support and more
We still have a lot of big plans and look forward to seeing how the Locust community continues to shape the project. Below is a taste of what’s on the horizon:
Locust Cloud
The biggest thing to happen to Locust in the last couple of years is of course the introduction of Locust Cloud. It is a hosted, enterprise ready solution for everyone who wants to run large load tests without having to manage load generation infrastructure or build reporting themselves.
Broader protocol support
Locust already supports User types for MongoDB, Postgres, and the most common type, HttpUser. But there are many other protocols you may want to test: you might want to test web sockets, or even send Kafka messages to a topic somewhere. A long time ago, I created a separate repo called locust-plugins containing a lot of extra features and User types, and plan to integrate more of these into Locust core to support more scenarios and make it easier for people who want to run different types of tests.
Also in the pipeline:
- AsyncIO support
- Migrate from Poetry to uv
- Proper support for in-browser tests using Playwright
- Experiment with Python 3.13’s new free threading mode (disabling Python’s global interpreter lock), to remove the need for multiple Locust processes
Why we still need Locust today
Locust is still the only “it’s just Python” load testing solution today. In the 13 years since Locust was created, Python has become the most popular programming language and is widely considered the best for beginners. Python’s prevalence makes it easy for us to build on the vast network of supporting frameworks and libraries to keep making it easier for people to extend Locust.
The next 13 years are sure to bring more innovations that demand even more and more complex load testing. We’d love to have your help, and invite anyone interested in contributing to check out our open issues to get started.
I’d also like to take this opportunity to thank the ~300 people who have already contributed code to the project. Locust wouldn’t be where it is today without your hard work! You rock! ❤️
Thanks for reading
Reach out to me if you have any questions!