Re:R3 – High-performance URL router library in C
by virtualwhys on Sunday May 18, 2014 @04:10AM
(#7762504)
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-a...
Re:R3 – High-performance URL router library in C
by pushrax on Saturday May 17, 2014 @10:21PM
(#7761913)
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)
Re:R3 – High-performance URL router library in C
by sjtgraham on Saturday May 17, 2014 @11:01PM
(#7761995)
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.
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
[2]: http://stackoverflow.com/questions/373098/whats-the-average-...