Open Bug 1290639 Opened 8 years ago Updated 2 years ago

Loading a single page in Firefox incurs 4 MB of read I/O in cert8.db

Categories

(NSS :: Libraries, defect, P3)

Tracking

(Not tracked)

People

(Reporter: gps, Unassigned)

References

Details

(Keywords: perf)

Attachments

(1 file)

Attached image cert8.png (deleted) —
I was using Process Monitor on Windows 10 (roughly equivalent to strace) to see what Firefox Nightly (2016-07-29) did during page loads. Nearly every time I use ProcMon with Firefox I find a seemingly alarming performance issue. Today's is with cert8.db. Opening a new tab and loading www.mozilla.org in Firefox results in 4 MB of read I/O to cert8.db. This was spread out over 256 read operations, each 16kb. AFAICT, this occurs on *every* page load. The good news is cert8.db is in the page cache, so none of that read I/O hits disk. The bad news is, well, we're doing queries on this SQLite database on every page load and SQLite is performing read I/O. The crazy thing is cer8.db is only 629 KB on my profile! I've attached a screenshot of the stack for one of the read system calls, but it isn't that descriptive. Attaching firefox.exe to a debugger, I can see slightly more details. It appears we're reading the SQLite database as part of mozilla::psm::CertVerifier::VerifyCert() and a number of other places when establishing TLS over newly-formed TCP connections. Although in a debugger I'm not able to reproduce the exact 4 MB of read I/O every time. I /think/ there may be a cache involved. And I /think/ the amount of read I/O amount might be proportional to the number of x509 certificates we need to verify and/or the number of TCP connections established. It's a Friday and I'm not really keen stepping through the debugger to figure out how Firefox's certdb works. Knowing nothing about how any of this works, it's tempting for me to make a blanket, ignorant, and probably incorrect statements like "if we have to perform I/O on page load to read certificates - data that likely changes infrequently and is a prime candidate for caching - we're doing something wrong." A more polite way of saying that is "the performance characteristics of reading from the certificate database don't feel right and might be making Firefox slower." Because it doesn't feel right, I'm filing a bug.
Opened Process Monitor tonight and observed this is still a problem on Nightly. Some tab or background process is opening a TLS socket every few seconds and I can see the heavy cert8.db file accesses every single time.
Keywords: perf
Well, I don't think anyone worked on this. So nothing changed. First I'm not sure why you think Firefox uses sqlite. Firefox still uses the legacy database (cert8.db), not sqlite (cert9.db). I see two ways forward here. i) Switch away from the legacy db. I expect the sqlite version to be more efficient. This would have to happen in PSM. ii) Fix the actual performance problem. For this we'd first have to profile what's actually going on. I guess we should do both.
This was likely resolved by Bug 1364159. If not, we'll catch it when we resolve Bug 783994 soon.
Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: