Closed Bug 1624685 Opened 4 years ago Closed 4 years ago

WebRequest API has unacceptable latency

Categories

(WebExtensions :: Request Handling, defect)

74 Branch
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1587058

People

(Reporter: rich, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

We have determined that there is a significant amount of network latency introduced when using the webRequest API in Firefox. This latency is introduced even with stub functions that don't do anything, regardless if Promises or objects are returned.

Example:

    const checkURLRequestWrapped = function(requestDetails) {
        return new Promise((resolve) => {
            resolve({});
        });
    }

    browser.webRequest.onBeforeRequest.addListener(
        checkURLRequestWrapped,
        {urls: ['http://*/*', 'https://*/*']},
        ["blocking"]
    );

Actual results:

To verify this, we created a website which measures unloaded and loaded latency for a sequence of images (http://demos.winstonprivacy.com/latency.html). We are seeing typical unloaded latency increases of 300% (90ms -> 275ms) on this page when the above listener is used inside of a web extension. There is a slight increase in latency if an object is returned instead of a Promise, but that could be within the statistical margin of error.

Expected results:

We should not expect latency to increase quite so much by adding a simple listener. In fact, we do not see this same latency problem in Chrome (typically just a few ms).

Interestingly, if the same demo website is hosted inside of the web extension (ie: the page and images are fetched locally), we see only a modest increase in latency (50ms -> 65ms).

This suggests that there might be something about the round trip time which is slowing request processing down more than it should, or perhaps the webrequest library is aware that the resource is local and is optimizing around that.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Request Handling
Product: Firefox → WebExtensions

Can you capture a profile of Firefox during your experiment? These instructions are a little dated but should basically work (you don't need a separate addon any more for profiling, it should be clear as you're going):
https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem

Flags: needinfo?(rich)

Great suggestion! I used the Gecko profiler as I already had it installed and ran the test page four times:

https://bit.ly/3dur9WE

Flags: needinfo?(rich)

In case it's helpful, here is a similar profile without the web extension. The latency was about 60-70% lower here.

https://bit.ly/2WI75ui

The profiler output is helpful. Filtering to just web extension code, most of the time is seen to be spent in jsWindowActor message handler.

Then looking at network activity, all of the requests have a delay of 140-165ms while waiting for a socket thread. This corresponds pretty closely with the latency delay we're seeing.

Rich, I'm curious if a non-blocking listener has a similar latency as the blocking listener, or if it is closer to running without an extension.

Flags: needinfo?(rich)

Hi Shane,

Non-blocking listeners do not appear to have a latency problem... they are comparable to running without an extension.

Flags: needinfo?(rich)

This is coming from bug 1587058, so I'm just closing this as dupe, but feel free to reopen if you think otherwise.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE

It's looking like this is a separate issue after all, so am re-opening this. Please feel free to continue the conversation in the other bug report if I am wrong.

The link below (which will expire in 7 days) points to a minimal web extension that does nothing. It simply registers two blocking event listeners and returns a promise that allows the request through.

https://send.firefox.com/download/a4e5ccd22fe72017/#__BuuQYLBkNq6yiJFXlytA

Here's a sample benchmark page that we use to measure web extension latency:

http://demos.winstonprivacy.com/latency.html

You can run the page with and without the dummy extension enabled to see the impact of latency. I'm running a high end laptop and I'm getting 100-150ms unloaded latency above what FF without an extension (or Chrome) exhibits.

Similar behavior is seen on Facebook, Gmail, Slack and other web apps that make many repeated calls to the same endpoint. This results in visible delays in Firefox and icons which are slow to load. The same sites in Chrome load quickly.

Any luck or progress with this? It is still a huge painpoint for Firefox.

Another use case that has turned up which may provide some motivation. Speedtests in Firefox with extensions installed tend to be an order of magnitude slower than in Chrome. Speedtests make many small, repeated requests to the same endpoint and is an extremely common use case, especially with more tech savvy FF users.

Chrome speedtest here just returned 470Mbps. Firefox returns anywhere from 90Mbps to 410Mbs (it is inconsistent).

(Order of magnitude may be overstating the case... but FF is definitely much slower).

You need to log in before you can comment on or make changes to this bug.