1594378 - The list of displayed HTTP requests doesn't seem to have maximum limit

Status: NEW

(DevTools :: Netmonitor, defect, P2)

Description

[Jan Honza Odvarko [:Honza] (always need-info? me)]

I had Network panel opened on a page that generates XHR over night and it shows that there is no limit (or is broken) for maximum amount of requests displayed.

There was more than 20K requests in my case and the browser was so slow that it was pretty much impossible to use.

It looks like that continuous addition of each new request into the big list (>20K <tr>s in a <table>) was very slow.
See profiler results: https://perfht.ml/2pNlp6p
(also GC could be expensive in this case)

The memory consumption of Nightly was more than 5GB

Honza

Comment 1

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Attachment: image.png

Here is a screenshot of Network monitor status bar.

• The transferred size wasn't that huge. So, it's more about number of requests in the list.
• The Finish time could show hours instead if minutes (we should have another bug for that)

Honza

Comment 3

[Hubert Boma Manilla (:bomsy)]

Will add a pref for the limit on display requests. maybe devtools.netmonitor.requests.limit: 500 (to match with the limit of the websockets panel).
Honza wdyt?

Comment 4

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Yes, sounds good to me.

Honza

Comment 5

[:Harald Kirschner :digitarald]

500 seems very low. With recent patches, the panel works well with 5000 requests in my testing. Console has a maximum of 10k messages. It would be easier to start at a higher bound and then lower it since we don't have an way for users to opt-out of it (like in WS inspector).

Shall we do 2000 as good middle ground?

The tangent idea for a follow-up bug to be a bit smarter about limit: If the panel is active, it could be 5000; but 1000 when its in background?

Comment 6

[Hubert Boma Manilla (:bomsy)]

That's a good point.
We won't want it too low, that users actively interacting with it, would always hit the limit.
The limit should be mostly for the "running in background" scenario.
I'm ok with 2k - 3k.

I like follow up idea ..
Another idea ... how about the limit kicks in a couple of secs (wait time) after the panel is not longer active also?

Comment 7

[:Harald Kirschner :digitarald]

Another idea ... how about the limit kicks in a couple of secs (wait time) after the panel is not longer active also?

Or simply bump it up once it was activated in a session. Most sessions never open Network panel (similar to Console only keeping the 1000 last messages before it opens).

Comment 8

[:Harald Kirschner :digitarald]

Filed bug 1615660 for the follow-up on background heuristics.

Comment 9

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to :Harald Kirschner :digitarald from comment #7)

Or simply bump it up once it was activated in a session. Most sessions never open Network panel (similar to Console only keeping the 1000 last messages before it opens).

Note that the Network panel doesn't collect anything until it's selected at least once in the session.

Honza

Comment 10

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to :Harald Kirschner :digitarald from comment #5)

Shall we do 2000 as good middle ground?

OK (I tend not to make it bigger since responses can take significant amount of memory)

Honza