[HN Gopher] Autotuner: How to speed up your Rails app
___________________________________________________________________
Autotuner: How to speed up your Rails app
Author : onnnon
Score : 131 points
Date : 2024-04-24 21:40 UTC (1 days ago)
(HTM) web link (railsatscale.com)
(TXT) w3m dump (railsatscale.com)
| Alifatisk wrote:
| Github: https://github.com/Shopify/autotuner
|
| It's incredible how much Shopify is investing in Rails (& Ruby
| for that matter).
|
| And I assumr the investment is paying off because otherwise they
| wouldn't continue like this.
| bigEnotation wrote:
| I wonder what the break even point would be to just have
| switched to use JVM.
| ajmurmann wrote:
| The problem is the "just switching" typically means a full
| rewrite and has a ton of logistic challenges. Are you gonna
| higher an entire second team? What happens to feature work on
| the current system? If you keep going full-throttle on
| features, you'll never catch up. If you stop developing
| features for a prolonged time, you are putting your entire
| business at risk.
|
| Writing new services in Java might help, but still doesn't
| solve the main issue if your Rails app is a monolith.
| Breaking up the monolith might be a bad decision and is also
| super expensive and might even eat lots of the potential
| performance gains.
| regularfry wrote:
| Rails on JRuby was a tenable proposition last I looked.
| Been a while though.
| norman784 wrote:
| JRuby is far behind CRuby, so there are a lot of gems
| that you can't use, also there are not too many companies
| investing in JRuby itself, IMHO CRuby it's a safer bet.
| mdaniel wrote:
| I believe TruffleRuby
| <https://github.com/oracle/truffleruby> is the state of
| the art for Ruby on the JVM, and
| <https://news.ycombinator.com/item?id=33503622> says that
| Mastodon works on it, so that's one data point. I haven't
| worked up the emotional energy to try to get GitLab to
| run on it
| ericb wrote:
| I was in a large org that did this for a while. It was
| extremely painful to be this far off the beaten path.
|
| When you stay in the well trod C Ruby path, you benefit
| from the hordes of others who cleared the landlines
| before you. With JRuby, not so.
| ransom1538 wrote:
| To save VM instance costs (not disks)? Probably never.
| bastawhiz wrote:
| Stripe tried switching lots of code to the JVM and it was a
| huge disaster. Unless you already have lots of small services
| with clean interfaces and their own data stores that can be
| incrementally switched, you spend far more time bending over
| backwards to keep two systems running (one with some limited
| parity with the other) in tandem.
|
| The cost of running the system is almost never bottlenecked
| by the performance of the language itself, but rather the
| responsibilities of the system and cleanliness of the code.
| Plus, in the migration, you start incurring the cost of your
| Ruby code calling your JVM code (and vise versa; your systems
| are almost certainly not a DAG), which almost certainly has
| higher overhead than whatever speedup you'd get from running
| code in the JVM in the first place. And then you're sharing
| protobufs/thrift files/whatever between different languages
| and libraries of varying degrees of quality (good luck with
| those Ruby protobufs!).
|
| Before you know it, writing a little tool to optimize your
| Ruby garbage collector sounds like a really great idea.
| gregors wrote:
| I think it's also a by-product of the CEO starting the company
| in Rails, and now having top engineers being part of Ruby core
| team or Rails core team. To a certain degree they'r steering
| the Ruby/Rails ship technically.
|
| Why would they bother switching if Shopify isn't having
| fundamental problems and they're the tog dog in their stack?
| whalesalad wrote:
| sunk cost
| andrewmutz wrote:
| I love to see how active and vibrant the Rails community is. I
| used to be concerned about the viability of building new
| companies in Rails, since the ruby share of languages is so low
| these days. Based on the still-healthy community and the
| ridiculous productivity level that a developer can have with
| Rails 7+ (turbo, morph, stimulus) I still think its a fantastic
| stack to build a company with.
| Syntaf wrote:
| From personal experience, I also appreciate that it's one of
| the easier stacks to keep updated with the latest and greatest.
| I've upgraded projects from sprocket-backed asset pipelines to
| bun in a couple days time, and the new tooling you get with
| modern rails really make upgrading worth it.
|
| Last year I started a new project[1] for a member management
| platform and really fell in love with the new jsbundling
| pipeline paired with stimulus, it feels like I've rekindled my
| passion that led me into programming initially; the ability to
| hack & prototype with rails is pretty unmatched (though it's
| worth mentioning Django holds a special place in my heart as
| well)
|
| [1] https://embolt.app
| RowanH wrote:
| I would imagine with cutbacks on spending/investing I think
| people getting leaner and meaner will re-visit the sheer
| productivity you can get out of it.
|
| Sure shaving the last 10/10ths of having a SPA with simple API
| based back end gets the ultimate user experience and speed but
| that cost curve goes up _significantly_ for that last 10th (if
| you were to compared to an 'old school' Rails app)
|
| I can't even fathom what it would have taken to build our
| startups' product in say React + Node (as an example..) vs OG
| Rails SSR. I look at a "sort of" competitor in our industry,
| and their rate of feature development is ridiculously slow by
| comparison.
| ecshafer wrote:
| If you haven't given Turbo and Stimulus a shot, I would
| recommend it. Way faster to write than React, and super fast
| and performant. I would say its definitely the way to go with
| Rails pages that aren't extremely simple.
| nickjj wrote:
| Yep, and you can also use it with any stack. I've
| successfully used both with Flask.
| RowanH wrote:
| Thanks! Definitely aiming to try them out
| rubymancer wrote:
| > I look at a "sort of" competitor in our industry, and their
| rate of feature development is ridiculously slow by
| comparison.
|
| Seconded. At my org, Ruby/Rails is our competitive advantage.
|
| Our 5-6 competitors are all Java/.NET shops -- we deliver
| fixes and new features dramatically faster and deploy them
| with ease. It gets noticed.
|
| The main downside is rails doesn't scale well re: complexity
| so regular refactors are necessary (ours is a high-volume big
| data app).
|
| For performance/cost, it took some doing but by strategically
| moving business logic to higher performance techs we've even
| managed to get to a great spot there.
| RowanH wrote:
| While certainly a little polarising the adage of optimise
| later really comes into play here. We do a lightweight
| industry specific system that had all the generic stuff (eg
| time/tasks etc) with some special sauce that makes us stand
| out. One of our clients said "Mate the rate you guys are
| adding features - the ERP company we went with they haven't
| done 1/10th of what you've done in the last year. Can you
| implement full multi-level bills of materials? "
|
| I said "no, can't do that - that's huge".
|
| A weekend later of experimentation (thanks to one very
| kick-butt gem on that has an amazing way of managing trees)
| "actually, we may just be able to - it's going to be a long
| road though - setting expectations..."
|
| A period of time later we've now implemented a full BOM
| planning/tracking system, tested well upto and beyond the
| numbers of items these types of companies expect.
|
| To the point they cancelled their renewal with a
| big/established ERP vendor and went with us instead.
|
| There's definitely some instances where speed to market
| trumps everything else. We can go optimise queries later
| on.
|
| What's been fascinating is I left my day job 2 years ago
| (to the month). We've gone from unheard of to becoming the
| market leader in our space. There is absolutely no way that
| could have been done with any other stack (without spending
| 5x the money - and I argue that co-ordinating a bigger
| developer team it almost wouldn't matter what money you
| throw at it, it gets exponentially harder getting everyone
| on the same page for delivery).
|
| At my old workplace I couldn't convince the .NET team for
| love nor money to look outside the box.
| neonsunset wrote:
| Because Ruby and especially RoR is a strict downgrade in
| every dimension compared to .NET. Now, these developers
| could have been using old .NET Framework, in which case
| we usually pretend they don't exist because it's like
| stubborn Python 2 of .NET that is otherwise the most
| productive platform for back-end (with really, really
| good performance).
| bdcravens wrote:
| I remember what happened in the early 2000s and how companies
| pulled back on the tech they were using. A few years ago I
| was convinced that fat front-end stacks are a luxury of
| companies with "free" money, and that the industry would be
| making tough choices. (To be clear, there are applications
| that the SPA approach is best for, but many applications are
| being built that could just as well be served by an old-
| school PHP and Jquery app)
| gedy wrote:
| I feel like this opinion is a bit stale, many companies use
| tools like NextJS, and it's as productive as Rails and not
| what I'd call "fat". The biggest issue some folks have are
| there's no standard ORM yet (maybe Prisma), but ORMs are
| not so critical with node or js based apps imho.
| bdcravens wrote:
| 3-4 years ago I was convinced that Rails was in its sunset
| years. JS had all the energy, Ruby conferences were
| disappearing, and it seemed like there was no new open-source
| development happening: we were all just using the same gems
| we'd used for years.
|
| I'm happy to say that I was proven very wrong. New conferences
| have sprung up, over-the-wire is trending well against SPAs,
| and there's been a ton of new features and approaches that have
| kept Rails and Ruby very relevant to modern development.
| atomicnumber3 wrote:
| I normally interview in Java, partly because I know it's
| deepest demons, and partly because pretty much anywhere will
| let you interview in it.
|
| But recently I interviewed for a staff engineer position and
| there was a portion that was "API programming." Just writing a
| basic REST API to CRUD a model object. And I was like, oh my
| god, I know what I have to do. So I used rails. It was an hour
| and 15 minute block, and I ran the interviewer out of
| extensions to the problem after 30-40 mins. So we just chatted
| for 20 more and then both went to an early dinner.
|
| (Unfortunately I didn't get the job - they were hiring a staff
| engineer but afaict ended up downgrading the seat to a senior
| engineer spot (50% the total comp) and rejected me and the
| other guy who was interviewing for the staff spot.)
|
| But damn did I feel like I properly represented Ruby and rails
| in that one interview.
| datascienced wrote:
| Maybe that was the problem, Rails and Ruby for this problem
| didn't demonstrate enough challenge for the role, so it
| didn't show you off enough in the interview.
| x0x0 wrote:
| with hotwire, rails is nearly a superpower. 90% of what react
| gives you at a tiny fraction of the dev time costs.
| xutopia wrote:
| And a fraction of initial load time... and HTML rendered on
| first load without adding anything to the framework.
| princevegeta89 wrote:
| Ruby is incredible. It is still one of the best choices for a
| platform to build a company or a product quickly with. If it
| cannot keep up with your scale, throw more hardware at it and
| it will still be worth it in terms of time and man-hours saved.
|
| I only ever wanted compile-time linting and better
| autocompletion such as in the case of Elixir LS. Does something
| like that exist for Ruby now? How is Crystal these days?
| TobiasBales wrote:
| There is ruby-lsp and ruby-lsp-rails. For the former to shine
| you do need to use sorbet but for any moderate to large sized
| rails app I'd personally recommend it anyway. Yes it's not
| perfect, yes it has a learning curve but boy does it make
| refactoring easier, faster and safer.
|
| ruby-lsp-rails builds on top of that and hands out
| information on models and routes mostly
| pqdbr wrote:
| Also using ruby-lsp with VS Code and it's been a game-
| changer.
| selykg wrote:
| This thread seems to be getting some views. I'm looking to
| break into the Rails work, but it seems rough trying to get
| into a job doing Rails work as a junior, not quite senior role.
| I have other development experience, primarily in Ruby and
| Objective-C.
|
| Any advice? I know the job market is a bit of a rough one right
| now as well.
| jupp0r wrote:
| Where do you get the idea that the rails ecosystem is striving?
| I work on a big Rails monolith as part of my day job and the
| amount of abandoned libraries in the ecosystem and general
| quality of libraries is pretty miserable if compared to Golang,
| Java, Python, JavaScript and others.
|
| I'm not saying it's a bad technology choice for a new company
| when all you need is to build a CRUD web app fast, but I
| wouldn't use it for anything that requires you to serve >1MB of
| JSON API responses or anything that requires concurrency,
| substantial IO, lots of API interactions with external
| services, low latencies, lots of memory or compute heavy
| computations, etc.
| jupp0r wrote:
| Just to give you a concrete example:
|
| We use grape-api for some of our API endpoints. I needed to
| set some custom cache headers for some GET API responses and
| was looking into gems that do that for grape. They have a
| list of 6 libraries in their docs [1] that they recommend.
|
| Their newest commits were 4, 9, 9, 10, 8 and 9 years ago,
| respectively. This is just one example, but I would bet half
| of the libraries in our transitive dependency tree haven't
| seen any maintenance in this decade.
|
| https://www.ruby-grape.org/projects/ [1]
| Syntaf wrote:
| Rails is *ancient* in the context of tech though, I think
| it's fair to criticize the skeletons in the closest while not
| necessarily refuting that the ecosystem is still active.
|
| An equivalent example imo is the PHP ecosystem, which itself
| has been growing rapidly and thriving over the years -- but
| at the same time if you did deep enough you'll find a
| graveyard of long since abandoned frameworks, libraries,
| etc...
| jupp0r wrote:
| I think both PHP and Ruby still have and will keep their
| niches, but in my opinion they don't provide the building
| blocks to expand outside of their niche and grow much at
| this point. If you contrast that with let's say Rust, which
| at least has the potential to become successful across a
| wide field of applications.
|
| The problem that I can see with Ruby in particular is that
| its niche is getting smaller and smaller as the world
| evolves around it. Interactions with external services that
| are on the critical path to serving requests are becoming
| more common. Interactions with actual contents of pictures
| and documents are becoming more common. Concurrency is a
| major missing building block to build modern apps compared
| to 10 years ago, and the answer of the Rails community has
| mainly been YAGNI (although there are efforts to
| incrementally improve things, but no fundamental shift in
| language or runtime design).
| daviding wrote:
| I tried this and couldn't get it to work on a Rail 7.1 Ruby 3.2,
| no output. The readme.md could do with some examples of what sort
| of recommendations come out. Edit: it outputs metric, just no
| recommendations so moving on.
___________________________________________________________________
(page generated 2024-04-25 23:00 UTC)