1693545 - Consider raising the priority of network IPC messages

Status: NEW

(Core :: Networking: HTTP, enhancement, P3)

Description

[Andrew Creskey [:acreskey]]

Bas had suggested an experiment where we increase the priority of select network IPC messages.

We had put together a small change where we added prio(mediumhigh) to OnStartRequest, OnTransportAndData and OnStopRequest messages.

In this case it was messages from the backgroundChannel to the content process.

In pageload tests we couldn't discern any performance improvements.

Comment 1

[Andrew Creskey [:acreskey]]

Attachment: Comparing the prio(mediumhigh) change with finer-grained metrics.

We have better tooling now, and so I compared the same change but measured the time from nsHttpChannel::asyncOpen to nsHttpChannel::OnStopRequest .

But I again found no measurable difference. (Live sites, Moto G5).

Comment 2

[Andrew Creskey [:acreskey]]

I tried one more experiment, this time increasing the priority of those messages from the httpTransaction (socket thread, I believe) to the parent process. Change here.

However, this didn't yield any measurable improvements.

Comment 3

[Andrew Creskey [:acreskey]]

If anyone has other ideas, please let me know.

It might be useful to try the combined changes, but perhaps I'm missing bottlenecked messages elsewhere?

Comment 4

[Kershaw Chang [:kershaw]]

(In reply to Andrew Creskey [:acreskey] [he/him] from comment #1)

Created attachment 9203972 [details]
Comparing the prio(mediumhigh) change with finer-grained metrics.

We have better tooling now, and so I compared the same change but measured the time from nsHttpChannel::asyncOpen to nsHttpChannel::OnStopRequest .

I think you might want tomeasure the time from HttpChannelChild::AsyncOpen to HttpChannelChild::OnStopRequest, since what you did is affecting the priority of IPC messages from parent to content process. The time spent in nsHttpChannel has nothing to do with IPC.

Comment 5

[Kershaw Chang [:kershaw]]

(In reply to Andrew Creskey [:acreskey] [he/him] from comment #2)

I tried one more experiment, this time increasing the priority of those messages from the httpTransaction (socket thread, I believe) to the parent process. Change here.

However, this didn't yield any measurable improvements.

PHttpTransaciton is only used when networking over socket process is enabled. Unfortunately, this function is not turned on currently, so this change should have no effect.

Comment 6

[Andrew Creskey [:acreskey]]

(In reply to Kershaw Chang [:kershaw] from comment #4)

(In reply to Andrew Creskey [:acreskey] [he/him] from comment #1)

Created attachment 9203972 [details]
Comparing the prio(mediumhigh) change with finer-grained metrics.

We have better tooling now, and so I compared the same change but measured the time from nsHttpChannel::asyncOpen to nsHttpChannel::OnStopRequest .

I think you might want tomeasure the time from HttpChannelChild::AsyncOpen to HttpChannelChild::OnStopRequest, since what you did is affecting the priority of IPC messages from parent to content process. The time spent in nsHttpChannel has nothing to do with IPC.

Thanks Kershaw.
I had thought that measuring at the nsHttpChannel level would still capture the delays involved in the parent-to-child initiation and data transfer.
But this is better -- let me re-measure from HttpChannelChild::AsyncOpen to HttpChannelChild::OnStopRequest

Comment 7

[Andrew Creskey [:acreskey]]

I measured the impact of mediumhigh priority on the HttpBackgroundChannel network messages.
(from HttpChannelChild::AsyncOpen to HttpChannelChild::OnStopRequest on a Moto G5).

------------------
baseline
count   3820.000000
mean     823.979319
std     1180.953931
min       36.000000
10%      130.900000
25%      215.750000
50%      403.000000
75%      961.500000
90%     2138.100000
95%     3074.650000
max    15732.000000
------------------
------------------
test
count   3767.000000
mean     878.641625
std     1273.867372
min       43.000000
10%      134.000000
25%      223.000000
50%      400.000000
75%      991.000000
90%     2399.800000
95%     3284.400000
max    14917.000000
------------------

I don't see any evidence of an improvement.

Ideally, I'd like to compare this on different hardware. And when we have Bug 1690373 ready, I think we can land such tests in CI.

But until then, I think we can close this one unless anyone has other ideas.

Comment 8

[Andrew Creskey [:acreskey]]

Using the same process that is described in these bugs ( 1690402 1690629) I've evaluated the impact of increasing the priority of PHttpBackgroundChannel and PHttpTransaction messages. Patch here.

The test measures total http channel completion time as the user visits 5 popular sites (cold page load), and then revisits them (warm pageload).

Results:
Linux: 5.51% improvement in channel completion time (from network) but not found to be statistically significant
MacOS: 3.36% improvement in channel completion time - both from network and from cache - but not found to be statistically significant
Windows: no change

So I find those to be interesting.
We've already seen many cases where the T-test that's used by perfherder fails to detect significant changes because of bimodal or otherwise noisy date. In Bug 1689373, the more appropriate Mann-Whitney-U test will be run alongside our current T-test.

I think I'm just going to run this test again and see what happens.
If we can keep reproducing these results then I think this has merit.

Comment 9

[Andrew Creskey [:acreskey]]

Unfortunately, the possible gains that I saw in Comment 8 did not reproduce.

Linux: overall network 5.23% slower
MacOS: overall network 0.99% slower
Windows: overall network 1.02% faster

If folks have ideas on other IPC messages to raise the priority of, let me know.
Otherwise I suggest closing this one.

Comment 10

[Andrew Creskey [:acreskey]]

We expanded on this experiment:

• also increasing the priority of events headed to the parent process.
• also trying the new event priority renderblocking

mediumhigh
https://treeherder.mozilla.org/perfherder/compare?originalProject=try&newProject=try&newRevision=0f05a746a9351e6442f09e48e66012a64877286e&framework=13&originalRevision=4e970e66e17b4a68c31430cbd0d46900b0f24f32&page=1

renderblocking
https://treeherder.mozilla.org/perfherder/compare?originalProject=try&newProject=try&newRevision=9e2e6057cc6754a9360fd0e253ccdc767a9d86ca&framework=13&originalRevision=4e970e66e17b4a68c31430cbd0d46900b0f24f32&page=1

They seemed to regress a good number of pages and improve a few.
Didn't pick up anything statistically significant on Speedometer2.
But the binaries are there for manual profiling if interested.