> If the application can’t saturate the CPU, there’s a fundamental problem. It’s a shame because it makes adding more servers less efficient. Money is being wasted on hosting costs, and this should be a priority to address. Talking about efficiency being a priority, but using RoR. I guess that is one way of saturating the CPU.
Ruby on Rails load testing habits
11–20 of 45 posts
Re: Ruby on Rails load testing habits
#12> If the application can’t saturate the CPU, there’s a fundamental problem. It’s a shame because it makes adding more servers less efficient. Money is being wasted on hosting costs, and this should be a priority to address. Talking about efficiency being a priority, but using RoR. I guess that is one way of saturating the CPU.
Re: Ruby on Rails load testing habits
#13> If the application can’t saturate the CPU, there’s a fundamental problem. It’s a shame because it makes adding more servers less efficient. Money is being wasted on hosting costs, and this should be a priority to address. Talking about efficiency being a priority, but using RoR. I guess that is one way of saturating the CPU.
If your application can’t saturate the CPU, Rails probably isn’t your bottleneck.
Re: Ruby on Rails load testing habits
#14Re: Ruby on Rails load testing habits
#15> If the application can’t saturate the CPU, there’s a fundamental problem. It’s a shame because it makes adding more servers less efficient. Money is being wasted on hosting costs, and this should be a priority to address. Talking about efficiency being a priority, but using RoR. I guess that is one way of saturating the CPU.
Rails has really poor startup time due to loading all codepaths. We switched to Django and it runs beautifuly on AWS Lambda where our CI is more expensive than actual server costs. We're a b2b application so traffic is quite low so we REALLY don't saturate the CPU in a normal Fargate setup.
Re: Ruby on Rails load testing habits
#16> My initial requirement was to send requests with unique parameters. To the best of my knowledge, no tool could do this. wrk does this with lua. https://github.com/wg/wrk/blob/master/src/wrk.lua Also even things like the venerable jmeter supported pulling parameters from a csv file.
I've never done load testing before, but would it be hard to write a script in pure ruby (maybe with a few libraries) that makes a lot of concurrent requests to whatever endpoints and using whatever params you like?
Re: Ruby on Rails load testing habits
#17> My initial requirement was to send requests with unique parameters. To the best of my knowledge, no tool could do this. wrk does this with lua. https://github.com/wg/wrk/blob/master/src/wrk.lua Also even things like the venerable jmeter supported pulling parameters from a csv file.
I've never done load testing before, but would it be hard to write a script in pure ruby (maybe with a few libraries) that makes a lot of concurrent requests to whatever endpoints and using whatever params you like?
Once you've got that out of the way, don't forget that you'll want a distribution story. It does not matter how efficient your tool might be on a single machine - you'll want to distribute your tests across multiple clients for real-world testing.
"Sure it's easy" you might say, "I know UNIX. Give me pssh and a few VMs on EC2". Well, now you've got 2 problems: aggregating metrics from multiple hosts and merging them accurately (especially those pesky percentiles. Your tool IS reporting percentiles rather than averages already, right?!), and a developer experience problem - no one wants to wrangle infra just to run a load test, how are you going to make it easier?
And, this developer experience problem is much bigger than just sorting out infra... you'll probably want to send the metrics produced by your tool to external observability systems. So now you've got some plugins to write (along with a plugin API). The list goes on.
I'm very biased, but it's 2024. Don't waste your time and just use https://www.artillery.io/
1. https://www.artillery.io/blog/load-testing-workload-models
Re: Ruby on Rails load testing habits
#18> If the application can’t saturate the CPU, there’s a fundamental problem. It’s a shame because it makes adding more servers less efficient. Money is being wasted on hosting costs, and this should be a priority to address. Talking about efficiency being a priority, but using RoR. I guess that is one way of saturating the CPU.
While you missed the point of the saturation comment, this is why we love AWS Lambda over ECS+Fargate. Rails has really poor startup time due to loading all codepaths. We switched to Django and it runs beautifuly on AWS Lambda where our CI is more expensive than actual server costs. We're a b2b application so traffic is quite low so we REALLY don't saturate the CPU in a normal Fargate setup.
Our ~500k lines app takes multiple seconds to start, which is why I'm not really investigating a lambda-style setup... Do you have specific strategies to make startup fast?
Re: Ruby on Rails load testing habits
#19Ruby with browser:
https://browserup.com/docs/en/load/ruby-load-test.html
Command-line installation: