Live data from Hacker News

Ruby on Rails load testing habits

rorvswild.com

21–30 of 45 posts

Re: Ruby on Rails load testing habits

#21

Having your test database mirror production as closely as possible is also an important habit, however I’m biased since that’s part of the offering that I’m building.

You might want to try and maintain a synthetic dataset for testing and staging that has the same "shape" as your production data - to avoid exposing sensitive data.

We're currently trying to have each rails model implement a #new_example method that builds a valid subgraph filled in by Faker, ready to save. Ie a

    user = User.new_example
will come with a Company.new_example if every user needs a company relationship.

Still early, we'll see how it goes.

Re: Ruby on Rails load testing habits

#22

> 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.

I have never seen Ruby on Rails be a bottleneck, and I have been using it since version 2.

Most bottlenecks are either that database choices or poor code/design choices by developers. That is especially true today.

Re: Ruby on Rails load testing habits

#23
post #17
post #4

Earlier quoted context omitted.

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?

Don't write your own load testing tool other than as a fun little exercise. At least not without understanding coordinated omission and thinking about workload modeling (open? closed? hybrid? all of the above?) [1]. Get this wrong and the results produced by your tool will be worthless. 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…

> founder - artillery.io

Re: Ruby on Rails load testing habits

#24
post #17

Earlier quoted context omitted.

Don't write your own load testing tool other than as a fun little exercise. At least not without understanding coordinated omission and thinking about workload modeling (open? closed? hybrid? all of the above?) [1]. Get this wrong and the results produced by your tool will be worthless. 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…

> founder - artillery.io

> I'm very biased

Re: Ruby on Rails load testing habits

#25
post #22

> 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.

I have never seen Ruby on Rails be a bottleneck, and I have been using it since version 2. Most bottlenecks are either that database choices or poor code/design choices by developers. That is especially true today.

Doesn't rails not have multithreading? How do you gather requests to batch your database calls?

A coworker made similar claims to me about Laravel, but the framework really encourages you to do half a dozen database queries in even a pretty minimal request, and for example implemented bulk inserts as a for loop that did single inserts. If you didn't know better with an access pattern like that, you might think the database is the bottleneck long before it actually should be. Is Rails different? My sense was they are very similar.

Re: Ruby on Rails load testing habits

#26
post #22

Earlier quoted context omitted.

I have never seen Ruby on Rails be a bottleneck, and I have been using it since version 2. Most bottlenecks are either that database choices or poor code/design choices by developers. That is especially true today.

Doesn't rails not have multithreading? How do you gather requests to batch your database calls? A coworker made similar claims to me about Laravel, but the framework really encourages you to do half a dozen database queries in even a pretty minimal request, and for example implemented bulk inserts as a for loop that did single inserts. If you didn't know better with an access pattern like that, you might think the da…

Rails supports multiple threads: https://guides.rubyonrails.org/threading_and_code_execution....

Rails has some tooling to help with query bloat: https://guides.rubyonrails.org/active_record_querying.html#e...

Re: Ruby on Rails load testing habits

#27
post #24

Earlier quoted context omitted.

> founder - artillery.io

> I'm very biased

I think mentioning you are a founder in the original comment might have prevented that particular reply from happening. I think one of the things I, personally, am becoming less okay with as a reader here is seeing recommendations without properly disclosing a connection.

Not saying everyone has nefarious reasons for doing it, but, it's just... everywhere.

I also play guitar, and there is a popular store in Europe with a pretty dang popular YouTube channel that I sometimes watch when the topic seems interesting. There was a whole kerfluffle a few months ago because one of the brand names that was getting a lot of air time on their YouTube channel was one that was financially backed by the owner of the store and a host of the channel. It took a ton of research of another YouTube to uncover this, and after it was found out, the owner of the store and host of the channel, finally disclosed his relationship with the brand he was promoting.

I feel like this was my more eye opening moment that tons of people out here on all variety of services are recommending their products but not disclosing their relationship clearly.

Now, you are saying so in your profile, but how many people are going to click into your profile?

I'm not saying you _have_ to do this, just suspecting that there are more and more people who are giving every recommendation the side eye these days because lack of disclosure. Disclosure isn't a bad thing, it just puts the bias in the open and people can gauge the recommendation more easily with that bias in mind.

None of this is probably new to you, but, trying to add something to the conversation rather than just call someone out, which is the easy and far more violent thing to do.

Re: Ruby on Rails load testing habits

#28
post #4

> 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?

There's a lot of subtleties. It's really easy to accidentally load test the wrong part of your web application due to differences in compression, cache hit ratios, http settings, etc.

Shameless self promotion but I wrote up a bunch of these issues in a post describing all the mistakes I have made so you can learn from them: https://shane.ai/posts/load-testing-tips/

Re: Ruby on Rails load testing habits

#29
post #26

Earlier quoted context omitted.

Doesn't rails not have multithreading? How do you gather requests to batch your database calls? A coworker made similar claims to me about Laravel, but the framework really encourages you to do half a dozen database queries in even a pretty minimal request, and for example implemented bulk inserts as a for loop that did single inserts. If you didn't know better with an access pattern like that, you might think the da…

Rails supports multiple threads: https://guides.rubyonrails.org/threading_and_code_execution.... Rails has some tooling to help with query bloat: https://guides.rubyonrails.org/active_record_querying.html#e...

Interesting. My understanding is that part of why mastodon is so slow/resource hungry is that it serializes background tasks to redis for a sidecar process to pick up, and that that's the normal way to do things. If rails has a concurrent runtime, why don't they just run background work directly?
Post reply on HN