Closed Bug 1271141 Opened 6 years ago Closed 6 years ago

WPT tests incurring gigabytes of I/O in Places SQLite database

Categories

(Testing :: web-platform-tests, defect)

Version 3
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: gps, Unassigned)

References

(Blocks 1 open bug)

Details

Same deal as bug 1271035. It's happening in WPT tests too.

From https://treeherder.mozilla.org/#/jobs?repo=try&revision=e276fe78829f161605f6e361090e001999cab152

                   Bytes Written
Linux64 Opt W1     1,745,862,656
Linux64 Opt W3     1,115,738,112
Linux64 Opt W4     1,557,487,616
Linux64 Opt W5     1,065,558,016
OS X 10.10 Opt W1  1,960,006,144
OS X 10.10 Opt W3  1,448,801,792
OS X 10.10 Opt W4  1,802,521,600
OS X 10.10 Opt W5  1,257,460,736

This is *system* bytes during the entire job. A few hundred MB will be e.g. extracting the binary and test archive. And, not all I/O incurred by SQLite hits the system (a lot gets serviced by the page cache). From local running with procmon, Places seems to be the source of most of the I/O during test execution however. The magnitude of the problem appears smaller, but it's definitely there.

I know WPT tests are a bit higher level than reftests. And I /think/ there are e.g. DOM features that may rely on Places working to pass. What I don't know is if WPT tests any of those.

Ms2ger: What are the concerns with disabling Places when running WPT? If some tests require Places, could we somehow annotate tests that require Places and enable Places only for those?
Flags: needinfo?(Ms2ger)
Blocks: fastci
I presume that tests requiring e.g. history.back will not work without places enabled. So just disabling it isn't going to work. Working out where it's safe to disable now is straightforward; we do a try run with it disabled and see where tests fail. The more challenging problem is keeping that information correct as we sync from upstream.
Flags: needinfo?(Ms2ger)
(In reply to James Graham [:jgraham] from comment #1)
> I presume that tests requiring e.g. history.back will not work without
> places enabled.

session history is different from global history and doesn't depend on Places. It should work.
Try seems to agree with you: https://treeherder.mozilla.org/#/jobs?repo=try&revision=c440a24a48ee&selectedJob=20553768

I'll do a bigger try run to check there isn't any platform-specific weirdness, but otherwise this looks good.

(if we think this is the right default for testsuites, it might make sense to edit prefs_general.js to set this pref, and then unset it for test[suites] where it is not wanted).
This landed as part of Bug 1273176
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.