698506 - (cookiesJank) cookies.sqlite written to very often

Status: RESOLVED WONTFIX

(Core :: Networking: Cookies, defect)

Description

[Dietrich Ayala (:dietrich)]

Lots of cookie.sqlite IO discussion in bug 572223.

I've noticed that cookies.sqlite is being written to constantly, according to my new profiling tool (Finder, sorted by last modified).

And it appears to correlate to some jank, detected using my new jank-detection tool (watching above profiling tool while also watching http://leaverou.github.com/animatable/ with "animate all" selected).

I need to isolate in a new profile with current sessionstore.js and cookies.sqlite, and flip cookies on/off, so this might yet be a red herring.

Comment 1

[Boris Zbarsky [:bzbarsky]]

When you say "constantly" do you mean on each page load, or continuously in general?

Comment 2

[Dietrich Ayala (:dietrich)]

It appears to not correlate directly to page load. Summary updated.

Comment 3

[[e-mail]]

We, uh, don't have main thread IO in cookies. You sure that's what's going on?

We do stuff on a background thread on pageload, but it's delayed and batched IIRC.

Comment 4

[Dietrich Ayala (:dietrich)]

Yeah could be red herring. But in my manual unscientific testing it certainly appeared as though the writes correlated to animation jankiness. Could be that something else not related happened at that point.

Comment 5

[[e-mail]]

Hmm. Yeah, it's always possible the cookie IO on the background thread is janking things; it's also possible that said async IO is blocking other things that *are* doing main thread IO. I bet you know the bug# on that one, I've seen it fly past.

Permission manager is related to cookies, and does do main thread IO. That shouldn't be getting invoked on pageload though.

Data would be nice, do you have a good way to instrument this?

Comment 6

[:Gavin Sharp [email: [e-mail]]]

(In reply to Dan Witte (:dwitte) from comment #5)
> Permission manager is related to cookies, and does do main thread IO. That
> shouldn't be getting invoked on pageload though.

Aren't there plenty of reasons for it to be invoked on pageload? nsCookiePermission::CanAccess is most relevant to this bug, but there's also other stuff like image loading permissions, indexedDB permissions, popup blocking permissions, etc? Basically everything we store there is relevant to content and can be triggered from loading web pages trying to do various things.

Comment 7

[Marco Bonardo [:mak]]

Just as a side not, cookies uses wal journaling, in this mode writes are cheap since they don't require to fsync. Still reducing traffic is always a welcome change.

Also looks like it uses synchronous OFF and fixed autocheckpoint of 16 pages, that in case you have an old db with a page_size different from default (32768) may be too small. Do we use synchronous = OFF because we don't care about corruptions? do we run integrity on this db? Recently I've seen a lot of complains about cookies disappearing or behaving strangely, I'd not want may be due to the fact we started ignoring their durability.

Dietrich, perf team may have a script to get a Storage prlog that distinguish mainthread queries from async queries, and they may even be able to decorate it with execution time for each query. Not sure if it's done yet, though, I suggested it many times.
Btw just with current PRLog you can check queries traffic.

Comment 8

[Shawn Wilsher :sdwilsh]

(In reply to Gavin Sharp (use [e-mail] for email) from comment #6)
> Aren't there plenty of reasons for it to be invoked on pageload?
> nsCookiePermission::CanAccess is most relevant to this bug, but there's also
> other stuff like image loading permissions, indexedDB permissions, popup
> blocking permissions, etc? Basically everything we store there is relevant
> to content and can be triggered from loading web pages trying to do various
> things.
The permission manager is like the cookie manager in that it has a hash table that has all the permissions in memory, so just reading them doesn't cause disk I/O of any kind (IIRC).

Comment 9

[Dietrich Ayala (:dietrich)]

Telemetry data is showing this is not a problem.