Closed Bug 1564184 Opened 5 years ago Closed 4 years ago

Under extreme load https/1 served large resources will not load via h2 proxy


(Core :: Networking: HTTP, defect, P1)




Tracking Status
firefox69 --- affected


(Reporter: mayhemer, Unassigned)


(Blocks 1 open bug)


(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.

Priority: -- → P2
Whiteboard: [necko-triaged]
Priority: P2 → P1

ni? :mayhemer to reproduce with new patches

Flags: needinfo?(honzab.moz)

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.

Closed: 4 years ago
Flags: needinfo?(honzab.moz)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.