News for hackers. Stuff that matters.
Re:Reasons to use Phoenix instead of Rails by WillPostForFood on Sunday November 26, 2017 @03:01PM (#15782676)
* 1 million requests an hour isn't that many.*

What percentage of websites serve 1 mil or more requests per hour, .01%? .001%? Meaning Rails is going to be performant enough for 99.9+% of projects, and for those projects it would have been a mistake to trade dev time for performance you’ll never need.

Re:Reasons to use Phoenix instead of Rails by phamilton on Sunday November 26, 2017 @04:34PM (#15783124)
1M request per hour at peak?

A SPA backed by rails is probably going to make at least 10 requests on page load. So in terms of actual traffic, 100k page loads during a peak hour. Assume a roughly linear peak increase/decrease and we've got roughly 1M page loads per day. 30M page loads per month.

How many websites have 30M (non-unique) page loads per month? After some rough scouting on Alexa ranks, I'd put the over-under at probably 10k US sites, and 50k worldwide. Assuming Alexa has 50M sites, then 0.1% of publicly facing sites serve that much traffic.

Rails is used often on private, internal sites and tooling. Those sites wouldn't come up. That would definitely skew the 0.1% number.

Not making a huge argument here, I just started down that analysis path out of curiosity and figured I'd share it.

Re:Reasons to use Phoenix instead of Rails by WillPostForFood on Sunday November 26, 2017 @04:58PM (#15783263)
Great analysis! According to Netcraft, there are > 600million websites, so assuming Alexa ignores the 550 million with near zero traffic, you can get to the .01% pretty easily. Another area I'd tweak is the skew towards SPAs. Most sites aren't SPAs, especially as you slide down the traffic rankings.
Re:Reasons to use Phoenix instead of Rails by phamilton on Monday November 27, 2017 @12:47AM (#15785137)
Yeah, the skew towards SPA is more Rails focused. I haven't worked on a non SPA Rails app in over 5 years. P(SPA | Rails) is higher than P(SPA).