Closed Bug 394492 Opened 12 years ago Closed 6 months ago
Store API performance issues with large number of windows and tabs
7.47 KB, application/zip
268.15 KB, image/jpeg
170.34 KB, image/jpeg
272.26 KB, image/jpeg
158.10 KB, application/zip
1.54 MB, text/html
63.01 KB, image/png
Please file one bug per individual issue and make them block this meta-bug. What will also help is if you could attach a sessionstore.js which causes trouble as a reference.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Well I had a very good one that someone sent me, but it contained personal data so I ended up erasing it. I put together something on my own that's not as good, but it does have 24 windows and 228 tabs. I'm trying to get someone to send me a better example. When I tested this in Firefox 126.96.36.199 with no plugins (searching for plugins disabled) or addons installed, it loads (eventually). After it loaded, I closed out all the windows and tabs and cleared all the private data and Firefox was using 75 MB of memory (63 MB VM). Compared with a starting browser state of 24 MB (13 MB VM) and 222 MB (211 MB VM) with all the windows/tabs open. Like I mentioned I think this is a memory leak in Firefox itself and not the Session Store API, but there are a large number of memory leak bugs already open.
Someone sent me this stored session. It only has 10 windows with a total of 96 tabs, but it nearly brings Firefox to its knees because it is about 2.1 MB in size (mostly seems to be cookies).
lots of js tabs can be problematic IMO might networking load cause problems, both external (as in causing a server to throttle you) and internal (as in windows or gecko not been efficient enough for the load)? I have an example that needs retesting. On big session restarts on a beefy laptop (wireless to cablemodem) I generally have no problem. But when it was logged in through a VPN, forcing all traffic through the VPN box and a different DNS server - potentially slowing the pipe as it were - then I had trouble with restore. Many of my tabs failed to load perhaps because of dns timeouts, these tabs gave a message to the effect of site or server not found. another thought - might it be possible, in extreme cases, to prompt the user for how much to restore in order to improve startup time? For example ignore tab history, don't load images (ala the netscape days), etc
OS: Windows XP → All
Hardware: PC → All
Would throttling the number of windows/tabs that open per second work here? Currently the restoreWindow function just opens the windows and restores things as fast as it possible can. If there was some kind of artificial user settable delay added I think that would satisfy cases where people either don't have powerful enough machines or fast enough connections to load all windows and tabs nearly simultaneously. Another possibility would be to open all the windows and tabs just as it's done now, but instead of actually loading the tabs, simply store the session state in the tab and have a button which when clicked restores the tab's state. Basically it would behave similar to the reload button page that shows up when a tab fails to load, except in this case when the button is pressed it would restore the session data into the tab.
It would be nice to get some movement on this bug, though if throttling isn't going to be used, then to really fix it properly would probably require threading.
Unfortunately I don't think any of those will run on my machine which is a Windows machine with an Intel processor.
CodeAnalyst should still work.
jprof of startup with profile from attachment 279228 [details]; trunk build pulled today. Not sure I'd categorize it as "severe performance problems" with current builds
Since the most recent comment, we've moved to a model where tabs are not actually loaded until accessed. Michael, can you test with a Nightly build? Taras: I'm removing the "P1" here because the data from Test Pilot shows that test-cases like this are *far* outside the norm.
Whiteboard: [Snappy:P1] → [Snappy]
(In reply to Dietrich Ayala (:dietrich) from comment #19) > Since the most recent comment, we've moved to a model where tabs are not > actually loaded until accessed. Michael, can you test with a Nightly build? > > Taras: I'm removing the "P1" here because the data from Test Pilot shows > that test-cases like this are *far* outside the norm. Can we get telemetry probes to confirm this? Test pilot is far from representative of overall population, telemetry is slightly better and will get better once we do it by default on nightlies.
(In reply to Taras Glek (:taras) from comment #20) > (In reply to Dietrich Ayala (:dietrich) from comment #19) > > Since the most recent comment, we've moved to a model where tabs are not > > actually loaded until accessed. Michael, can you test with a Nightly build? > > > > Taras: I'm removing the "P1" here because the data from Test Pilot shows > > that test-cases like this are *far* outside the norm. > > Can we get telemetry probes to confirm this? Test pilot is far from > representative of overall population, telemetry is slightly better and will > get better once we do it by default on nightlies. Yea, let's figure out what exactly we need and make that happen in bug 671041 (if it makes sense), though I'm wont to believe the Test Pilot numbers Dietrich is talking about.
Dietrich I'd like to keep this as P2 until we have telemetry data that can show otherwise. Marking as P2 because it shouldn't block other work, but it would be nice to have this.
Whiteboard: [Snappy] → [Snappy:P2]
This is a meta bug that doesn't go into the backlog.
Flags: firefox-backlog? → firefox-backlog-
Taras, David, what do you both think about closing this bug? We restore on demand by default for a while now and since this bug was filed sessionstore also started to load at most three tabs concurrently when restoring a multi-window session. I'm not sure what telemetry measurements exactly we were talking about here but I don't know of any cases where single tabs don't load or show timeout dialogs since we have cascaded restore.
(In reply to Tim Taubert [:ttaubert] from comment #24) > Taras, David, what do you both think about closing this bug? We restore on > demand by default for a while now and since this bug was filed sessionstore > also started to load at most three tabs concurrently when restoring a > multi-window session. I'm not sure what telemetry measurements exactly we > were talking about here but I don't know of any cases where single tabs > don't load or show timeout dialogs since we have cascaded restore. This is more of a Vladan question.
glandium used to keep very large sessions until recently and he says that he has seen more than 3 or 4 tabs being loaded simultaneously, as well as some tabs not loading at all (with "server not found" errors) I think this bug is still valid. Can we try reproducing this again?
Flags: needinfo?(vdjeric) → needinfo?(ttaubert)
Ok, let's put this into the backlog and find some time to investigate whether this is still valid and reproducible.
Whiteboard: [Snappy:P2] [tracking] → [Snappy:P2]
Whiteboard: [Snappy:P2] → [Snappy:P2][fxperf]
I habitually work with hundreds of tabs per session (recently around a thousand, down from ~1,500 a few months ago). This is the type of bug to which I'd like to contribute, however from my point of view it'll not make sense until bugs such as this are progressed: 1381922 - Allow modifying/restoring back-forward history for each tab <https://bugzilla.mozilla.org/show_bug.cgi?id=1381922> > Blocks: Session_managers – followed by a reasonable period, maybe a few months, for things to form around new (or reintroduced) capabilities. Also I'm on Tier-3 FreeBSD so no Gecko Profiler, and so on.
Ehrm.. I'm not sure about what happens when you (I understand?) *want* to load every tab at once But at least since bug 1345090 landed, even 2000 not-currently-loaded tabs are a breeze.
Ehrm indeed :-) Before the 2017-08-08 release of Firefox 55 my sessions – with no greater than 54.x (I'm certain, because it's pretty much releases-only on FreeBSD) – were around 500 tabs. With my choices of extensions, sessions with _too many_ more (than 500 tabs) were memorably impractical. I never imagined finding a need to share this type of screenshot :-) – and I simply haven't got around to weeding these oldest sessions – but for posterity, here's a Session Manager set with 477 tabs across ten windows, the July before 55 …
(In reply to mirh from comment #29) > … even 2000 not-currently-loaded tabs are a breeze. Yes and no, YMMV. Inarguably, 55 then 57 brought the greatest leaps – most noticeable when _extension-free_ but that is, for me, non-realistic. (So, off-topic, I'm with Waterfox for now.) Fast forward to 60. When I last spent some time experimenting with something approaching a realistic set of extensions, things were (for me) not close enough to breezy with ~1,050-tab sessions. tl;dr 60 seemed somehow more of a drag than 59 but I couldn't easily get a hands-on sense of why that might be (and here's not the place to go into detail). That was three weeks ago. ---- Partly off-topic, here's that point from three weeks ago: https://www.reddit.com/r/waterfox/comments/8iyfef/-/ ONLY if anyone would like to chime in, on Reddit, with advice on how best to reuse, in Firefox 60, a session that's written by Waterfox 56.2.x.
If you are handling sessions in that way, then I'm 99% sure you should follow bug 1427928, and ask the corresponding extensions developer to check for lazily loading of tabs, best current practices and whatnot. I believe "SessionStore" itself is fine, if when instead I use built-in save mechanism I haven't particular problems. And probably this decennial issue has run its course.
Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.