Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

core(driver): request smaller trace in m71+ #6117

Merged
merged 8 commits into from
Oct 15, 2018
Merged

Conversation

paulirish
Copy link
Member

@paulirish paulirish commented Sep 26, 2018

Backstory in #3596.

Results: cnn.com's trace goes from 69M to 47M.

--

  • Using Browser.getVersion and parsing out the chrome milestone. We can augment this pattern later for isMobile and os like @patrickhulce suggested.
  • I made a lil sendCommand mock response helper in driver-test. There are similar stubs for on() and once().
  • we now default to the new disabled-by-default-lighthouse category and fallback to 'toplevel', as @brendankenny very wisely suggested
  • ideally i'd like to drop the SCHEDULABLE_TASK_TITLE possibilities from FOUR down to 2. But it requires updating a lot of fixture data. So we can do that in a followup.

Copy link
Member

@brendankenny brendankenny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

other thoughts:

  • we could fix the FIXME in driver.getUserAgent and use Browser.getVersion. Then this could be a call to (await driver.getUserAgent()).product instead of putting it on the pass context
  • if not, and hostUserAgent is just going to be on the pass context until m71, put a TODO?
  • if you think hostUserAgent on there isn't going to be temporary, should we preparse the UA string it so gatherers can just consult the version number?

// TODO(COMPAT): Once m71 ships to stable, change the traceCategories for real
const reChrome71 = /Chrome\/(Headless)?7[1-9]/;
if (passContext.hostUserAgent && reChrome71.test(passContext.hostUserAgent)) {
traceCategories.forEach((cat, idx) => {
Copy link
Member

@brendankenny brendankenny Sep 26, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why forEach? Do we anticipate multiple ones? Maybe this should be changing this._traceCategories. It's very very unlikely, but in case someone is passing in 'toplevel' into additionalTraceCategories and they really mean it :)

could also use map instead of forEach

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe this should be reversed as well. Have disabled-by-default-lighthouse be the default and replaced by toplevel in Chrome < 71. Then future edits just have to change things here

Copy link
Collaborator

@patrickhulce patrickhulce left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so it's just RunTask? was that really all it took? 😲 amazing! 😃

@@ -402,6 +401,7 @@ class GatherRunner {
// If the main document redirects, we'll update this to keep track
url: options.requestedUrl,
settings: options.settings,
hostUserAgent: baseArtifacts.HostUserAgent,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was parsing the user agent over in #5893, maybe after this we should do a refactor for some useful host.chromeVersion, host.isMobile, host.os?

@patrickhulce
Copy link
Collaborator

I'm mildly nervous about missing some random lantern-impacting event, but I think we've both been through it multiple times before.

@paulirish
Copy link
Member Author

ptal

Copy link
Collaborator

@patrickhulce patrickhulce left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so exciting :D lookin' real good


// In Chrome <71, gotta use the chatty 'toplevel' cat instead of our own.
// TODO(COMPAT): Once m71 ships to stable, drop this section
const milestone = (await this.getBrowserVersion()).milestone; // eg 'Chrome/71.0.3577.0'
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it feels like this comment should be up where the regex is that parses out 71 :)

@@ -46,9 +48,23 @@ function createActiveWorker(id, url, controlledClients, status = 'activated') {
};
}

function createOnceMethodResponse(method, response) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

someday using jests mock functions would be awesome :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah our lame driver/connection mocking everywhere is ripe for a cleanup.

createOnceMethodResponse('Browser.getVersion', m70BrowserVersion);

// eslint-disable-next-line max-len
return driverStub.beginTrace().then(() => {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

want to use async/await for new code?

getUserAgent() {
return Promise.resolve('Fake user agent');
const browserVersion = {
protocolVersion: '1.3',
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this doesn't return milestone. Is this filename wrong and it's really not a fake driver but a fake connection?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good catch. yeah the separation between protocol response vs driver method response got a little mixed up.

Clarified this now.

Copy link
Collaborator

@patrickhulce patrickhulce left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@paulirish paulirish merged commit b878616 into master Oct 15, 2018
@paulirish paulirish deleted the adjusttracecats branch October 15, 2018 17:35
Copy link
Member

@brendankenny brendankenny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since RunTask is the future, we should also update create-test-trace.js to use it

const milestone = (await this.getBrowserVersion()).milestone;
if (milestone < 71) {
const toplevelIndex = traceCategories.indexOf('disabled-by-default-lighthouse');
traceCategories.splice(toplevelIndex, 1, 'toplevel');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems like the splice is unnecessary?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

traceCategories[toplevelIndex] = 'toplevel' sgtm

const SCHEDULABLE_TASK_TITLE_ALT2 = 'ThreadControllerImpl::RunTask';
const SCHEDULABLE_TASK_TITLE_ALT2 = 'ThreadControllerImpl::DoWork';
// m65 and earlier
const SCHEDULABLE_TASK_TITLE_ALT3 = 'TaskQueueManager::ProcessTaskFromWorkQueue';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

have you thought about a long-term support plan for these? Supporting old trace versions seems pretty good if it's not much work, but otoh our test traces are increasingly not looking like traces from master

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I'd like to redo all our fixture traces. Right now it doesn't seem too bad..
.. I just tested the perf downside of checking the evt name four times and its probably a maximum of ~10ms total on a big trace. So we can ignore that bit.

I think it's aiight for now. But we'll put something in the OKRs about freshening up our fixtures/mocking/test infra.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, definitely not a performance issue (string compares are fast, especially if they haven't ever been modified), and since the events all more or less cover the subset of events we're interested in (we only have to do the string check, not more convoluted fixes to support each), it's more a case of being able to easily see what the state of the world is in the code.

The downside for updating fixtures (besides being really annoying to do) is we get less coverage of the old versions, so we may want to really phase out support completely for some of these if we actually do that.

@@ -46,9 +48,23 @@ function createActiveWorker(id, url, controlledClients, status = 'activated') {
};
}

function createOnceMethodResponse(method, response) {
assert.deepEqual(!!sendCommandMockResponses[method], false, 'stub response already defined');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

deepEqual left over from an earlier revision?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wrote the method assuming someone else may try to use it. And just wanted to assert no one was going to use it twice.
I can remove though if you don't see the value.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can remove though if you don't see the value.

sorry, I think it's fine, I meant the deepEqual is kind of overkill because they're both booleans :)


const mockResponse = sendCommandMockResponses[command];
if (mockResponse) {
delete sendCommandMockResponses[command];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should use a Map for things like this

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont see why Map is better, but happy to change it. :)

@paulirish
Copy link
Member Author

since RunTask is the future, we should also update create-test-trace.js to use it

sg will do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants