4 ms·

(Pre-disclaimer: I think it's great that the author spent some time benchmarking and hacking, and I don't mean for this comment to tear down their work, but rat

by evmar 12y ago

(Pre-disclaimer: I think it's great that the author spent some time benchmarking and hacking, and I don't mean for this comment to tear down their work, but rather I'm just answering the above question which was also the first thing that came to my mind when I saw this.) The slowest URL router benchmarked there[1] does 10462.0 runs per second, which is just under 0.1ms per run. I'm not sure what performance is expected of Rails handlers but the first stackoverflow thread[2] that came up on a simple Google search had twitter doing 600 req/s across 180 instances which comes to 300ms per request. By that math, the slowest URL router costs 0.033% of the request overhead. Caveat: 300ms/req is slower than you'd like for an interactive website; real websites may have more complicated routing tables than this benchmark. Counter-caveat: 0.1ms is not enough to matter pretty much anywhere except for the stock market. [1]: https://github.com/c9s/r3#benchmark https://github.com/c9s/r3#benchmark [2]: http://stackoverflow.com/questions/373098/whats-the-average-requests-per-second-for-a-production-web-application http://stackoverflow.com/questions/373098/whats-the-average-...

pushrax 12y ago
In addition, if you were to replace the Rails router with a Ruby trie implementation, it would be even faster. (not that this is encouraged)
- sjtgraham 12y ago
  I wrote the trie implementation referenced in the benchmarks. I didn't do it for speed, I did it because I couldn't add the router functionality I needed using the existing underlying implementation.
  - pushrax 12y ago
    Cool, nice work! I didn't actually look at the benchmark and was just making (perhaps poor) assumptions. I'd imagine it does come with a nice little performance boost though?
virtualwhys 12y ago
The linked SO answer is fairly dated (2011), Twitter is able to handle bursts of up @140K req/s (with Scala) as of last year[1] Assume Rails has improved hugely since then, 600 req/s over 180 instances is absolutely abysmal performance O_o I'd expect Rails to clock in well under 300ms per request now, and looking at Basecamp's site[2], that seems to be the case, impressively snappy page loads (if caching the kitchen sink and not hitting live Rails stack then we'd need to look at a different example, but this site has pretty much optimal load time). [1] https://blog.twitter.com/2013/new-tweets-per-second-record-and-how https://blog.twitter.com/2013/new-tweets-per-second-record-a... [2] https://basecamp.com https://basecamp.com

by evmar 12y ago

pushrax 12y ago

In addition, if you were to replace the Rails router with a Ruby trie implementation, it would be even faster. (not that this is encouraged)

sjtgraham 12y ago
I wrote the trie implementation referenced in the benchmarks. I didn't do it for speed, I did it because I couldn't add the router functionality I needed using the existing underlying implementation.
- pushrax 12y ago
  Cool, nice work! I didn't actually look at the benchmark and was just making (perhaps poor) assumptions. I'd imagine it does come with a nice little performance boost though?

virtualwhys 12y ago

The linked SO answer is fairly dated (2011), Twitter is able to handle bursts of up @140K req/s (with Scala) as of last year[1] Assume Rails has improved hugely since then, 600 req/s over 180 instances is absolutely abysmal performance O_o I'd expect Rails to clock in well under 300ms per request now, and looking at Basecamp's site[2], that seems to be the case, impressively snappy page loads (if caching the kitchen sink and not hitting live Rails stack then we'd need to look at a different example, but this site has pretty much optimal load time). [1] https://blog.twitter.com/2013/new-tweets-per-second-record-and-how https://blog.twitter.com/2013/new-tweets-per-second-record-a... [2] https://basecamp.com https://basecamp.com