Open Bug 1594378 Opened 5 years ago Updated 1 month ago

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

Categories

(DevTools :: Netmonitor, defect, P2)

defect

Tracking

(Not tracked)

People

(Reporter: Honza, Unassigned)

References

(Blocks 2 open bugs)

Details

Attachments

(1 file)

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

Attached image 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

Summary: The list of request doesn't seem to have maximum limit → The list of displayed HTTP requests doesn't seem to have maximum limit

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?

Flags: needinfo?(odvarko)

Yes, sounds good to me.

Honza

Flags: needinfo?(odvarko)

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?

Flags: needinfo?(hmanilla)

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?

Flags: needinfo?(hmanilla)

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).

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

See Also: → 1615660

(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

(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

Severity: normal → S3
See Also: → 1896461
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: