Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby on Rails load testing habits

rorvswild.com

Post reply on HN
Print view View original

41–45 of 45 posts

Re: Ruby on Rails load testing habits

#41

Post by edgyquant »

ndriscoll wrote: post #37
edgyquant wrote: post #36

Earlier quoted context omitted.

Having a redis job queue is extremely standard, especially for web app development, regardless of language. For one thing if the web server crashes for any reason the jobs still continue processing and also you have a log of jobs in case they fail etc

Are people using it for reliability though? Are they running redis in a mode where it persists a journal? If not, then if redis crashes for any reason, you're in the same situation. And, like, Mastodon apparently uses a queue to do things like send new user registration emails. Why not just send the email from the new user request handler? Then if there's an error, you can tell the user in the response instead of say…

It may just be out of habit and not any underlying language reasoning. Things like sending emails or doing anything but simple database operations make sense to do in a queue. For instance I’ve worked at multiple places where we did this using celery and python or bullmq/javascript. Some of them we did have a log that persisted for a certain amount of time so we could rerun e.g. emails that never got sent

Re: Ruby on Rails load testing habits

#42

Post by bdcravens »

e12e wrote: post #21
pistoriusp wrote: post #14

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

Wouldn't it be easier to do the same with FactoryBot? It'll similarly cascade creation of associated records.

Re: Ruby on Rails load testing habits

#43

Post by e12e »

bdcravens wrote: post #42
e12e wrote: post #21

Earlier quoted context omitted.

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

Wouldn't it be easier to do the same with FactoryBot? It'll similarly cascade creation of associated records.

I don't enjoy documenting the graph in two places, first in models, then in factories.

But yes, the pattern is essentially the same, just our example methods and Faker - without Factory Bot.

Re: Ruby on Rails load testing habits

#44

Post by bdcravens »

e12e wrote: post #43
bdcravens wrote: post #42

Earlier quoted context omitted.

Wouldn't it be easier to do the same with FactoryBot? It'll similarly cascade creation of associated records.

I don't enjoy documenting the graph in two places, first in models, then in factories. But yes, the pattern is essentially the same, just our example methods and Faker - without Factory Bot.

I can understand that. I prefer keeping my models clean without environment-specific implementation details, which is why I've settled on the FactoryBot approach for testing, seeding, etc.

Re: Ruby on Rails load testing habits

#45

Post by irjustin »

cocoflunchy wrote: post #18
irjustin wrote: post #15

Earlier quoted context omitted.

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.

I'm surprised to see a mention of Django when talking about fast startup times! This is one of my main issues with Django at the moment. How big is your project? 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?

Apologies on the lay reply.

Your app is significantly bigger than ours, so grain of salt.

We play very close attention to what's loaded on startup. There are two key tricks.

1. Heavy libraries/packages load at runtime and are only in the "background job" codepath.

  def my_heavy_func():
    from heavy_library import sum_heavy_function
    
    sum_heavy_function()
vs the import at top of file.

2. Limit which apps are loaded via `INSTALLED_APPS`, again no heavy packages.

Lambda is SUPER nice for us. The bottleneck becomes the DB. Webserver can basically never go down on its own as you can create 1000x by default.

Best of Luck!

Post reply on HN