*## On Perf Changes* Any performance improvements that have wide implications such as this, need to be benchmarked before they could be merged.
It's not enough to do the research, we would need actual experimental proof that it works, provides a significant speed boost to justify the extra code costs and doesn't have any major downsides. If you add a new feature, it has to be tested. If you do a perf change, it needs to be benchmarked. It's not good enough to shoot in the dark *## On multiple asset hosts* You can do this today. Rails accepts a proc for the asset_host that you can use to randomize an asset host however... I looked into this extensively in the last 6 months and the general consensus is that it doesn't help much, and even then it can make performance slower. Most connections are fast these days, but the overhead in making new connections is still there. Basically the browser doesn't know that www.domain and www1.domain are the same and must connect separately. The result can be a slower page render. Go ask igrigorik, he knows this stuff backwards and forwards (browser behavior and speed). Here's two good articles https://insouciant.org/tech/network-congestion-and-web-browsing/ http://perf.fail/post/96104709544/zealous-sharding-hurts-etsy-performance *## However* If you feel strongly, go test it. Build up repeatable benchmarks and instructions for others to run them. Don't take my word on this, test it. On Fri, Oct 31, 2014 at 10:33 AM, Sebastian Korfmann < korfmann.sebast...@gmail.com> wrote: > Hey there, > > I've been wondering if the assumption of four asset hosts for the sake of > speed improvements is still valid. > > Rails documentation about asset hosts: > > Browsers typically open at most two simultaneous connections to a single >> host, which means your assets often have to wait for other assets to finish >> downloading. You can alleviate this by using a %d wildcard in the >> asset_host. For example, “assets%d.example.com”. If that wildcard is >> present Rails distributes asset requests among the corresponding four hosts >> “assets0.example.com”, …, “assets3.example.com”. With this trick >> browsers will open eight simultaneous connections rather than two > > > According to this (http://www.browserscope.org/?category=network), > browsers are supporting typically 6 - 8 simultaneous connections per host > nowadays. However, there's an average max connection limit of 2 times of > that. > > Would it make sense to adjust the behaviour to generate only two asset > hosts by default? > > Cheers, > > Sebastian > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rubyonrails-core+unsubscr...@googlegroups.com. > To post to this group, send email to rubyonrails-core@googlegroups.com. > Visit this group at http://groups.google.com/group/rubyonrails-core. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
