[ehsanu1]

I've seen numerous big rails apps with times as long or longer, even after decent effort has been put in to optimize. Generally a case of having a lot of things on a page and rendering it all into html server-side (the classic/old rails way of doing things).

[jashmatthews]

300ms from server side rendering requires something self inflicted. Even bulk JSON endpoints should be faster than that.

27ms is the average dynamic response time for Basecamp, which is server side rendered HTML done the classic way.

I worked on a high performance Rails API serving dynamically generated map tiles and our response times were actually lower than that.

[nirvdrum]

Doesn't basecamp do a ton of caching to achieve response times like that? There are certainly techniques to get there, but how long does it take to populate the caches? That's what you're going to see out of a stock Rails app.

Self-inflicted, sure. But in my experience it's the result of picking developer-friendly tools to optimize for developer time. Erubis is much faster than HAML, but a lot of developers prefer the latter. Those sorts of decisions accumulate.

[jashmatthews]

No more than Match.com do, who run on .NET. Basecamp just uses the standard Rails caching AFAIK.

Templating just isn't the issue now that it was in the days of 1.8. HAML is slower than ERB, but usually neither have a meaningful impact on response time on modern Ruby. ERB is approaching Erubis performance now.

[ehsanu1]

I worked on a high performance Rails API serving dynamically generated map tiles and our response times were actually lower than that.

Sounds like an ideal case for fast response times honestly. I've seen rails endpoints like that aplenty. But there also exists a lot of stuff taking hundreds of ms on a cold cache, and it's the kind of thing where the same effort done in the same way using another language ecosystem would just be 10x as fast.

If you've never seen this, perhaps you've never worked with a large monolithic rails app with a few years of legacy code built up? Brand new API endpoints can be a lot faster of course.

[jashmatthews]

10x faster in, say, Go? Are you sure? Have you benchmarked it? You might be surprised.

Lets pick a weakness of Ruby: tight loops and lots of math. Take 16,000 GPS points and calculate the geographical distance to another point.

On my machine it takes 12-14ms in Ruby and 4-6ms in Go. That's only a little bit more than twice as fast! Almost certainy not worth re-writing your entire app for.

I've worked with a bunch of large, legacy Rails apps. In between a couple of Rails jobs, I worked on a large .NET app, which didn't have much better performance. One service I helped migrate from Rails to Spring/Java for an enterprisey client actually got slower overall, despite moving to the JVM.

[jashmatthews]

These are the response times for Discourse, a complex open-source Rails app. Even the slowest endpoint has an average response time of 46ms.

Percentile: repsonse time (ms) categories_admin: 50: 17 75: 18 90: 22 99: 29 home_admin: 50: 21 75: 21 90: 27 99: 40 topic_admin: 50: 17 75: 18 90: 22 99: 32 categories: 50: 35 75: 41 90: 43 99: 77 home: 50: 39 75: 46 90: 49 99: 95 topic: 50: 46 75: 52 90: 56 99: 101