RESOLVED FIXED Bug 40852
Limit simultaneous DNS prefetch request number 
https://bugs.webkit.org/show_bug.cgi?id=40852
Summary Limit simultaneous DNS prefetch request number
Alexey Proskuryakov
Reported 2010-06-18 13:29:59 PDT
We currently queue up to 64 requests, and fire them all at once. Making 64 requests at once can overwhelm some routers. <rdar://problem/8105498>
Attachments
proposed fix (3.71 KB, patch)
2010-06-18 13:46 PDT, Alexey Proskuryakov 		ggaren: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1 2010-06-18 13:46:12 PDT
Created attachment 59150 [details] proposed fix
Darin Adler
Comment 2 2010-06-18 13:48:16 PDT
Comment on attachment 59150 [details] proposed fix Using a HashSet means the order of the names is based on hash table ordering, essentially random. Should we do something to preserve the order?
Geoffrey Garen
Comment 3 2010-06-18 13:55:44 PDT
Comment on attachment 59150 [details] proposed fix r=me How did you test that this scheme does not overwhelm important gateways?
David Levin
Comment 4 2010-06-18 13:57:07 PDT
Since you are fixing the comment on line 58 of WebCore/platform/network/cf/DNSCFNet.cpp, maybe you can fix a spelling error as well "appications'".
Alexey Proskuryakov
Comment 5 2010-06-18 13:59:32 PDT
I am not aware of a strong reason why ordering would be important (my comment in code about dropping newer names notwithstanding). > How did you test that this scheme does not overwhelm important gateways? We know that chromium uses 8 parallel requests (because it has 8 loader threads), so I'm relying on matching them. Also, a co-worker seems to be able to reproduce the problem, so we'll test to see if a nightly resolves it.
Alexey Proskuryakov
Comment 6 2010-06-18 14:06:38 PDT
Committed <http://trac.webkit.org/changeset/61435>.
Note You need to log in before you can comment on or make changes to this bug.