2 ms·
Also how slow is still ok? People can talk about things that aren't 'performance sensitive' but at some point it's going to matter Done a fair amount
by JohnBooty 4y ago
Also how slow is still ok? People can talk about things
that aren't 'performance sensitive' but at some point
it's going to matter
Done a fair amount of Rails perf tuning over the years. One of my favorite things to work on.
"Fast enough" for me, is when your web framework is nowhere near your bottleneck. On your average web app endpoint you're probably spending 95-99% of your time on external calls to Redis/Postgres/etc and Postgres is probably your specific bottleneck.
For these apps, Rails is most definitely fast enough. You could rewrite your app layer in well-tuned C or assembly and guess what, it's getting maybe 1-5% faster if you're lucky. Maybe you get from 100ms down to 95ms and all you had to do was rewrite 100,000 lines of Ruby in 200,000 lines of C.
For other cases, obviously, maybe Rails is your bottleneck. Maybe you're providing a read-only API and everything is cachable in RAM. Rails will be fast, maybe 10ms per request, but a faster framework can spew out responses in 2ms and now you have 5x the capacity and your P95s during peak hours are really smoothed out.
- ksec 4y agoFor Rails as an API? Yes. There are plenty of examples where Rails as an API, and specifically not using ActiveRecord, gets you 10ms response time excluding DB. But most of the Rails app, especially those with ActiveRecord and Server side rendering spend 60+% of response time, And in many cases even higher before hitting DB. And they fall into 100 to 200ms response time category.