Bug 40852

Summary: Limit simultaneous DNS prefetch request number
Product: WebKit Reporter: Alexey Proskuryakov <ap>
Component: PlatformAssignee: Alexey Proskuryakov <ap>
Status: RESOLVED FIXED    
Severity: Normal CC: darin, levin, psolanki
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: Mac   
OS: All   
Attachments:
Description Flags
proposed fix ggaren: review+

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+
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
Note You need to log in before you can comment on or make changes to this bug.