Bug 262780 – Web process cache should expire old web processes sooner

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit2

[Michael Catanzaro]

Currently the web process cache has a default 30 minute timeout for expiring old web processes. This is pretty excessive, and it's contributing to user complaints regarding excessive memory use from unused cached web processes. (Yes, the cache should be evicted under memory pressure, but users still don't like seeing applications use huge amounts of RAM.) The use case is: open 20 tabs for https://reddit.com, then close them all and continue using the browser. All those web processes stick around using a whole lot of RAM for up to 30 minutes.

The current web process cache defaults are:

Seconds WebProcessCache::cachedProcessLifetime { 30_min };
Seconds WebProcessCache::clearingDelayAfterApplicationResignsActive { 5_min };
static Seconds cachedProcessSuspensionDelay { 30_s };

I'm thinking the default cachedProcessLifetime should be much smaller, say at most 5 minutes. If you don't visit the same website again for more than 5 minutes, it's surely OK to pay the cost of spinning up a new web process, right?

Hey Chris, would you be OK if we change this for all platforms? I'm thinking Safari users would appreciate a shorter cache lifetime as well.

P.S. More details on how the cache works in bug #219689

[Chris Dumez]

(In reply to Michael Catanzaro from comment #0)
> Currently the web process cache has a default 30 minute timeout for expiring
> old web processes. This is pretty excessive, and it's contributing to user
> complaints regarding excessive memory use from unused cached web processes.
> (Yes, the cache should be evicted under memory pressure, but users still
> don't like seeing applications use huge amounts of RAM.) The use case is:
> open 20 tabs for https://reddit.com, then close them all and continue using
> the browser. All those web processes stick around using a whole lot of RAM
> for up to 30 minutes.
> 
> The current web process cache defaults are:
> 
> Seconds WebProcessCache::cachedProcessLifetime { 30_min };
> Seconds WebProcessCache::clearingDelayAfterApplicationResignsActive { 5_min
> };
> static Seconds cachedProcessSuspensionDelay { 30_s };
> 
> I'm thinking the default cachedProcessLifetime should be much smaller, say
> at most 5 minutes. If you don't visit the same website again for more than 5
> minutes, it's surely OK to pay the cost of spinning up a new web process,
> right?
> 
> Hey Chris, would you be OK if we change this for all platforms? I'm thinking
> Safari users would appreciate a shorter cache lifetime as well.
> 
> P.S. More details on how the cache works in bug #219689

I oppose this change, please do not change it for Apple ports.

One thing you didn't seem to consider is that those processes have warm caches and are thus able to load sites (from the same origin) much faster than a freshly launched process. It is not just a process launch optimization.

Also, on Apple ports, these processes get evicted on memory pressure. There is virtually no cost to keeping them around. They use RAM, so what? If we need that RAM, we'll kill them.

[Michael Catanzaro]

(In reply to Chris Dumez from comment #1)
> One thing you didn't seem to consider is that those processes have warm
> caches and are thus able to load sites (from the same origin) much faster
> than a freshly launched process. It is not just a process launch
> optimization.

Hm, that's surprising. OK, let's not do this then.

[Michael Catanzaro]

We've continued to receive complaints from users regarding the cache lifetime. Let's use 5 minutes for GTK/WPE, and probably also other non-Cocoa ports too, as it's likely a more suitable default for most platforms. (As mentioned above, Apple wants to keep the 30 minute lifetime for Cocoa platforms.)

[Michael Catanzaro]

One odd thing I notice is that the 30 minute cache lifetime applies only if the application remains "active" as determined by NSApplicationDidBecomeActiveNotification and NSApplicationDidResignActiveNotification. That is, if the user ever focuses another application on Cocoa platforms, then the 5 minute lifetime applies forevermore. In practice, this means that users who Alt+Tab to another application once every 5 minutes are going to see the 5 minute cache lifetime.

It is not hooked up to focus change events on WPE/GTK, so Linux users always get the 30 minute cache.

I wonder if the intended behavior was to have two separate timers, on 30 minute timer and one 5 minute timer, where the cache gets evicted only if application remains unfocused for 5 minutes. Changing the cache lifetime based on whether the application is unfocused for any amount of time doesn't make sense to me.

[Michael Catanzaro]

Pull request: https://github.com/WebKit/WebKit/pull/24286

[Michael Catanzaro]

Hm, it looks like, on Apple platforms, processes will be cached indefinitely if the user unfocuses the window, refocuses it (so it becomes active, causing the eviction timer to stop), and does not leave it unfocused for more than 5 minutes (which restarts the 5 minute timer).

I seriously doubt this is the desired design. Hi Chris, do you want a bug report for this? Maybe I'm missing something?

[EWS]

Committed 275063@main (29ee71944f91): <https://commits.webkit.org/275063@main>

Reviewed commits have been landed. Closing PR #24286 and removing active labels.

[Radar WebKit Bug Importer]

<rdar://problem/123328910>