New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 21 users

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: May 30
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Feature

Blocking:
issue 313280


Show other hotlists

Hotlists containing this issue:
Hotlist-1


Sign in to add a comment

Reconsider optimal connection-per-host limit

Reported by tonyg@chromium.org, Sep 5 2013

Issue description

Currently chrome limits to 6 connections per host. It appears IE10 has increased to 8 connections per host.

We've experimented with this before and found 6 to be optimal. But now that we have a new rule of a max of 10 images in parallel, perhaps the optimum is different.

 
There's some alternate proposals about doing this more dynamically per
client from Van Jacobson and others. Will try to dig them out. Would prefer
that, but a static change may help.

Comment 2 by souders@google.com, Sep 5 2013

If we're comparing to IE10 it's worth noting that Opera 8-10 did 8 connections per hostname but they dropped to 6 connections per hostname as of Opera 11. 

http://www.browserscope.org/?category=network&v=1

Despite this move in the other direction I think it's worth investigating increasing this value in Chrome. If possible, I would like to try increasing it only for hostnames that have N+ queued requests (where N is ~20). 

Across the world's top 300K the median website has 39 resources on a single domain. 90%ile = 97, 95%ile = 127, avg = 50.

Related blog post: http://www.stevesouders.com/blog/2013/09/05/domain-sharding-revisited/
Status: Untriaged
Just for posterity's sake, I'm going to write down my comment on souders' proposal which I already described to people offline.

I'm concerned about increasing parallelism when queues build up. Another reason that queues build up is network contention/congestion/etc. When problems happen, we should avoid making it worse. This proposal has the possibility of improving the median case, but may also damage the long tail cases. As I've already discussed with the speed team folks, we should be focusing on the long tail, as that's often where we're hurting.

And as I said internally, I'm fine with re-running tests since it's relatively cheap for James to spin up a new build and send to Pat to testing. That said, I build that we should focus on longer-term, more dynamic solutions, like dynamically choosing configuration based on network characteristics.

Comment 4 by dxie@chromium.org, Nov 13 2013

Status: Available

Comment 5 by tonyg@chromium.org, Nov 13 2013

Cc: pmeenan@chromium.org oysteine@chromium.org

Comment 6 by tonyg@chromium.org, Nov 13 2013

Blocking: chromium:313280

Comment 7 by oysteine@google.com, Nov 13 2013

How about only spinning up new connections if some X% or more of the current connections to the host are just idle waiting for first response, as I suggested during simonjam@'s presentation? That should help remedy the problematic case where we spend a lot of time just waiting for small resources (the size of the resource could also be taken into account).

Comment 8 by benm@chromium.org, Jan 9 2014

Cc: primiano@chromium.org benm@chromium.org andreip@chromium.org

Comment 9 by benm@chromium.org, Jan 10 2014

Hi folks,

re #3, did the tests get rerun? It would be great to see any results.

If not, can we consider doing that pending longer term changes to move to a dynamic solution?

Thanks
Ben
I can build with a few different configs and re-run the tests but the tests usually target a reasonably small number of connection types (1-2) and a relatively small set of sites (2000 in the desktop suite, 1000 in the mobile suite).

I believe the last time we ran the test was the desktop suite on the DSL connection profile (1.5Mbps, 50ms RTT).  These days we mostly test Cable for Desktop (5Mbps, 28ms RTT) and a Fast 3G profile for mobile (1.6Mbps, 150ms RTT).

The tail issues in the field are probably not going to come from either one of those profiles - high latency, high bandwidth will look good with more connections, low latency low bandwidth will look good with fewer.

Do you want to see the test re-run for the desktop and mobile profiles with 4, 6, 8 and 10 connections?  Ultimately for a static value change you're going to want to do it as a field trial to see the impact at the different percentiles.

Smarter logic that takes into account the estimated RTT to the host for a given pool, some guess of the connectivity and some understanding of other outstanding requests (if all of the resources are coming from a single domain, open up the pool a bit) will be the best but it's going to be a bear to pull off.

Comment 11 by benm@chromium.org, Jan 10 2014

Cc: klo...@chromium.org
Thanks Patrick!

It would be great to gather some initial data, especially if I understood right and we haven't run this particular test on a mobile profile before. I think we're most interested in seeing how an *increase* in max connections per host affects load time, so could probably exclude 4.

How are the profiles created? Would it make sense to also come up with a "slow" 3G profile? (Or maybe Edge/GPRS?)

Perhaps based on this data we can move into a field trial, but I'm not familiar with what's involved in setting that up.

Many thanks
Ben
The profiles are all done using dummynet so we can tune the connectivity parameters to be anything we'd like.  Our normal 3G profile has the same bandwidth but 300ms RTT.  Each permutation adds a lot of tests so narrowing down the connectivity and connection count permutations to the smallest group would be helpful.

I can start off just testing Mobile with fast and normal 3G with 6 and 10 connections if you'd like and then we can take it from there.

Comment 13 by benm@chromium.org, Jan 10 2014

Fantastic, that would be great.

We've also had a proposal that increasing to 18 provides good results, but I understand there may be some other constants (like max parallel image downloads) that need changing too. I think folks are skeptical (myself included) that a large increase to 18 will give generally good results, but it would be interesting to see the data if it's possible to run the tests in that configuration too.

Really appreciate the help :)
Test is done.  6, 10 and 18 connections on the fast and normal 3G connections: https://docs.google.com/spreadsheet/ccc?key=0As3TLupYw2RedDk3WElWV0t5WDNGd1NTOURoUEExX1E&usp=sharing (should be world-readable)

On the Fast 3G connection, the metrics we care about most (Page Load, Dom Content Ready, Speed Index and Start Render) got pretty much universally slower as we increased the concurrent connections (2-3% or so).  On the 3G connection with higher latency it was a mix of some metrics getting slightly better and others slightly worse.

For the 10 and 18 connection tests, the 10 concurrent image limit was removed.

Comment 15 Deleted

Cc: -willchan@chromium.org

Comment 17 by bua...@gmail.com, Sep 18 2015

I would really appreciate if Chromium team can help us on this.
Owner: cbentzel@chromium.org
Status: Assigned
 Issue 578864  has been merged into this issue.
Owner: ----
This has not been modified in over a year. I'm assigning you from these shackles. If you think this is in error, please correct me.
Labels: -Performance Performance-Browser
Status: Available (was: Assigned)
Project Member

Comment 22 by sheriffbot@chromium.org, May 8

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Owner: lassey@chromium.org
With HTTP/2 and QUIC providing multiplexed connection I wonder how much value there is in perusing this feature. It certainly doesn't seem high on the priority list. I propose we close it unless there is some compelling data which would cause us to revisit.

lassey: assigning this to you to see if you're convinced by my argument :) If so feel free to close.
Status: WontFix (was: Untriaged)
Closing, per comment #23.  Not opposed to revisiting it, just doesn't seem worth the effort.

Sign in to add a comment