Under extreme load https/1 served large resources will not load via h2 proxy
Categories
(Core :: Networking: HTTP, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox69 | --- | affected |
People
(Reporter: mayhemer, Unassigned)
References
Details
(Whiteboard: [necko-triaged])
I have a locally (IIS) hosted speed test (or more a download exhauster) webapp that, when running via h2 proxy, fails to load significant number of the resources (25 origins) while the server is configured to disable h2.
It's very hard to diagnose as MOZ_LOG changes timing/ordering and things just load. Filed bug 1564139.
According wireshark (which is not able to capture all the packets - too fast - and hence session's tls stream can't be followed) the data (likely all of it) is delivered to the failing streams.
But fetch() in the webapp says that the operation was aborted (which IMO means it generally failed).
This works perfectly in chrome.
|
||
Updated•5 years ago
|
|
Reporter | |
Updated•5 years ago
|
|
|
Reporter | |
Comment 2•5 years ago
|
||
Still using only my local proxy. We behave differently, depending on settings. When I disable h2 on the server, we are OK now and the speeds are significantly higher for different download sizes.
When the server is h2 enabled, I still see issues, but I believe all are known.
One issue with settings at:
const default_size = 4 * 1024 * 1024; //bytes
const default_interval = 50; //ms
const default_higher_set = 'A'; // default is 'ABCDE'
const default_lower_set = [1]; // default is [1,2,3,4,5]
const default_multiplier = 2; //single run automatic multiplier
const use_single_domain = false; //just let the domains generator return 25 times the same domain
makes all requests to fail. we get unexpectedly from the server a RST/0xD (HTTP_1_1_REQUIRED) frame during the content delivery, on each downloading stream. This seems like an IIS bug to me.
Other issue is that after few runs of the test we hit limits and requests are indefinitely queued:
2019-07-31 14:57:00.017000 UTC - [Parent 1088: Socket Thread]: V/nsHttp nsHttpConnectionMgr::AtActiveConnectionLimit [ci=TSA.....[tlsflags0x00000000]speed-test-001-a.local:443 (https:localhost:3000)[:] caps=31,totalCount=6, maxPersistConns=6]
2019-07-31 14:57:00.017000 UTC - [Parent 1088: Socket Thread]: V/nsHttp AtActiveConnectionLimit result: true
likely bug 1565242 as I can see the 'A' flag in the connection entry key.
The original issue, though, seems to WFM now (probably the dragana's 59sec patch). Closing.
Description
•