The list of displayed HTTP requests doesn't seem to have maximum limit
Categories
(DevTools :: Netmonitor, defect, P2)
Tracking
(Not tracked)
People
(Reporter: Honza, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
image/png
|
Details |
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
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Comment 1•5 years ago
|
||
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
Reporter | ||
Updated•5 years ago
|
Comment 3•5 years ago
|
||
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 5•5 years ago
|
||
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•5 years ago
|
||
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•5 years ago
|
||
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•5 years ago
|
||
Filed bug 1615660 for the follow-up on background heuristics.
Reporter | ||
Comment 9•5 years ago
|
||
(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
Reporter | ||
Comment 10•5 years ago
|
||
(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
Updated•2 years ago
|
Description
•