ProxyResolution thread can use significant CPU on high request documents
Categories
(Core :: Networking: Proxy, enhancement, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox141 | --- | fixed |
People
(Reporter: acreskey, Assigned: kershaw)
References
(Blocks 3 open bugs)
Details
(Whiteboard: [necko-triaged][necko-priority-queue] )
Attachments
(1 file, 1 obsolete file)
It was observed in Bug 1904284 that we can spend a lot of CPU cycles in the ProxyResolution thread if there are a lot of requests.
Profile: https://share.firefox.dev/4bGMGZk
Kershaw suggest that we could optimize this as we did in bug 1392272 (reverted in bug 1749501):
However, I do see an opportunity here. From the all-thread sample, I notice that the ProxyResolution thread uses ~30% CPU resources. I think it would be beneficial to revisit bug 1392272 (which was reverted in bug 1749501) to avoid reading system proxy settings for every HTTP request.
| Reporter | ||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 1•11 months ago
|
||
The initial patch in bug 1392272 was backed out because it didn’t handle the proxy exception list correctly.
The first step would be to add a test to ensure that future changes don’t cause regressions.
I plan to work on this bug soon.
| Assignee | ||
Comment 2•11 months ago
|
||
Previously, we called the Android system proxy API via JNI for every new request.
With this change, the proxy config is cached, allowing us to reuse the result and avoid repeated JNI calls.
| Reporter | ||
Updated•11 months ago
|
| Assignee | ||
Comment 3•11 months ago
|
||
Updated•11 months ago
|
| Reporter | ||
Comment 5•11 months ago
|
||
I compared this patch again on the newssite-applink-startup applink_startup (without profiling runs) but it did not pick up any improvements.
Comment 6•11 months ago
|
||
| bugherder | ||
Updated•10 months ago
|
Description
•