Domain sharding is still useful but our guidance is outdated. It's from a pre-SSL-everywhere, pre-SPDY era where browsers had low per-domain connection caps.
http://www.stevesouders.com/blog/2013/09/05/domain-sharding-revisited/ http://blog.cloudflare.com/using-cloudflare-to-mix-domain-sharding-and-spdy/ (TIL that chrome will "unshard" SPDY requests to different hosts with the same IP and SSL cert!) On Fri, Oct 31, 2014 at 10:38 AM, richard schneeman <richard.schnee...@gmail.com> wrote: > ## 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. -- 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.
