1998646 - Increase priority of DoH/DNS runnables.

Status: RESOLVED DUPLICATE of bug 2009372

(Core :: Networking: DNS, task, P2)

Description

[Valentin Gosu [:valentin]]

See (In reply to Valentin Gosu [:valentin] (he/him) from bug 1994314 comment #9)

I think the delay makes sense.
The socket thread is busy, so the processing of the transaction dispatched from mozilla::net::TRRServiceChannel::Connect will wait in the queue behind other things.
Then when the DoH response is received, we'll process the sockets in order mozilla::net::nsSocketTransportService::DoPollIteration, so we might actually do other things rather than process the DoH response.
Then we read from the socket, the data goes to the TRR thread, we parse the packet, we call nsHostResolver::CompleteLookupLocked, which then goes to mozilla::net::DNSListenerProxy::OnLookupComplete that dispatches to the original thread that called AsyncResolve. In the common case when the resolution was triggered from mozilla::net::DnsAndConnectSocket::TransportSetup::ResolveHost this was the socket thread, so we need to wait for event queue to be processed yet again in order for the connection to proceed.

2. Increasing the priority of the runnables posted to the socket thread:

• mozilla::net::nsHttpConnectionMgr::AddTransaction already has a priority attribute.
• The other runnable we'd need to increase the priority for would be mozilla::net::DNSListenerProxy::OnLookupComplete

We want to increase the priority of DNS runnables, as that is likely to make channels be dispatched a bit faster.

Comment 1

[Valentin Gosu [:valentin]]

Attachment: WIP: Bug 1998646 - Increase priority of DNSListenerProxy::OnLookupComplete runnables r=#necko

Comment 2

[Valentin Gosu [:valentin]]

https://perf.compare/compare-lando-results?baseLando=163372&newLando=163373&baseRepo=try&newRepo=try&framework=13

Comment 3

[Andrew Creskey [:acreskey]]

In this try push I included the patch from this bug to increase the priority of the DNSListenerProxy::OnLookupComplete runnable.
From a very quick look at a resulting profile, this does not appear to be the bottleneck because I still see many 300-600ms trr lookups.
https://share.firefox.dev/49wco4J

Related, in bug 2007582 I'm adding more CI dns tests, trr and OS resolver.

Comment 4

[Valentin Gosu [:valentin]]

A version of this landed in https://phabricator.services.mozilla.com/D280956