Cian Butler

That's got good and bad.

It meant that previously we would have like the memory and CPU would stay flat.

But now like as requests went up, you could actually see the CPU was going up and down because we were doing more work.

And we were like, that's a good signal for us scaling now.

We could use that to do some auto scaling where previously we couldn't do that auto scaling.

Exactly, yeah.

So we sat down and we drew up a testing scenario, like some numbers we wanted to see, some testing we want to do.

Which parts of the stack could we try removing now that we just, and could we just replace it with Kranian?

So we did a lot of different load tests to the point we actually managed to bottleneck in the load test tooling.

We hadn't scaled the load test tooling up high enough that it could push enough throughput in one of our tests that we needed to step back and change the load test tooling out.

for, we were previously using Locust, which is a fantastic load test tool for where you manage stuff in, you write your load test in Python and you can, and then you spin on top lots of Python workers that are managed and it does the load test from different places.

But those workers were becoming our bottleneck.

So, well, they're not really a bottleneck.

How much money we were willing to spend on those workers became the bottleneck.

Like how many workers could you spin up for a load test was the bottleneck.

So we switched out for a tool called Goose, which was a reimagining of that in Rust.

Managed to push for the same amount of workers.

We were able to push more requests, like I think 100 or 1,000x more requests per worker, which meant that bottleneck was out the window.

I think that was the biggest signal of we can push more was when we had to swap out the load testing tool because that was what was being saturated.

Yeah.