2 ms·

Why is there no Ruby web framework in the most iconic benchmark [0]? [0]: https://www.techempower.com/benchmarks/# https://www.techempower.com/benchmarks/#

vidarh 4y ago
You're moving goalposts. Gone from "complexity" to performance. Ironically I'd have been more willing to agree with you that the complexity of Mastodon is a challenge. But presumably because very few people cares about that benchmark and what is supported depends on what they choose to add. You're the first person I've ever seen mention it. For a simple reason: Performance on dynamic requests is a choke point only for a miniscule proportion of sites, and the federation that is a selling point for Mastodon ensures that any single Mastodon instance is far less likely to ever approach a size where that becomes an issue. There are certainly sites where I wouldn't run Ruby, even though it's a language I love to use. But I'll repeat myself: The choice of Ruby is far down the list of issues with Mastodon. Returning to the benchmark, it's also contrived to reference as a general measure for a web app. Anyone building actual systems using Ruby puts Ruby behind a reverse proxy exactly because we're fully aware you focus on avoiding hitting the Ruby app server for anything static or cacheable, and so the setups on that benchmark (there are at least four frameworks and a couple of dozen entries) are entirely atypical for Ruby app server setups (they all hit the web server hosting the Ruby app directly). That's fine - they measure what they measure, but they don't measure a realistic web app setup with any relevance to Mastodon. E.g. the vast majority of traffic for a Mastodon instance is read-only requests to toots and media that are trivially statically cached, and so the vast majority of hits to a Mastodon server set up to actually scale should never hit the app server at all. I have a deep distaste for Rails, and think Mastodon is more complex than it needs to, and there's plenty to criticise Mastodon for, but you're barking up the wrong tree.

vidarh 4y ago

You're moving goalposts. Gone from "complexity" to performance. Ironically I'd have been more willing to agree with you that the complexity of Mastodon is a challenge. But presumably because very few people cares about that benchmark and what is supported depends on what they choose to add. You're the first person I've ever seen mention it. For a simple reason: Performance on dynamic requests is a choke point only for a miniscule proportion of sites, and the federation that is a selling point for Mastodon ensures that any single Mastodon instance is far less likely to ever approach a size where that becomes an issue. There are certainly sites where I wouldn't run Ruby, even though it's a language I love to use. But I'll repeat myself: The choice of Ruby is far down the list of issues with Mastodon. Returning to the benchmark, it's also contrived to reference as a general measure for a web app. Anyone building actual systems using Ruby puts Ruby behind a reverse proxy exactly because we're fully aware you focus on avoiding hitting the Ruby app server for anything static or cacheable, and so the setups on that benchmark (there are at least four frameworks and a couple of dozen entries) are entirely atypical for Ruby app server setups (they all hit the web server hosting the Ruby app directly). That's fine - they measure what they measure, but they don't measure a realistic web app setup with any relevance to Mastodon. E.g. the vast majority of traffic for a Mastodon instance is read-only requests to toots and media that are trivially statically cached, and so the vast majority of hits to a Mastodon server set up to actually scale should never hit the app server at all. I have a deep distaste for Rails, and think Mastodon is more complex than it needs to, and there's plenty to criticise Mastodon for, but you're barking up the wrong tree.