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

ref(apm): Always use monotonic clock for time calculations #2485

Merged
merged 8 commits into from Mar 11, 2020

Conversation

HazAT
Copy link
Member

@HazAT HazAT commented Mar 10, 2020

Refactoring of our time calculations, now everything is based on monotonic timeOrigin.

@HazAT HazAT requested a review from rhcarvalho March 10, 2020 10:47
@HazAT HazAT requested a review from kamilogorek as a code owner March 10, 2020 10:47
@HazAT HazAT self-assigned this Mar 10, 2020
@HazAT HazAT changed the title ref: Always use monotonic clock for time calculations ref(apm): Always use monotonic clock for time calculations Mar 10, 2020
@kamilogorek
Copy link
Contributor

Can we get this in the same PR as well please? getsentry/sentry-python#644 (comment)

@HazAT
Copy link
Member Author

HazAT commented Mar 10, 2020

@kamilogorek I think this is not relevant, we never did this.

Copy link
Contributor

@rhcarvalho rhcarvalho left a comment

Choose a reason for hiding this comment

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

We managed to do a nice clean up, awesome!!

packages/utils/src/misc.ts Show resolved Hide resolved
packages/apm/src/span.ts Show resolved Hide resolved
packages/utils/src/misc.ts Show resolved Hide resolved
packages/apm/src/span.ts Outdated Show resolved Hide resolved
packages/apm/src/integrations/tracing.ts Show resolved Hide resolved
packages/apm/src/integrations/tracing.ts Show resolved Hide resolved
packages/apm/src/span.ts Outdated Show resolved Hide resolved
@@ -460,6 +453,7 @@ export class Tracing implements Integration {
logger.log('[Tracing] finishIdleTransaction', active.transaction);
// true = use timestamp of last span
active.finish(true);
Tracing._resetActiveTransaction();
Copy link
Contributor

Choose a reason for hiding this comment

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

@HazAT could you remind me what this fixes?

Wondering if we need to call it from more places.

Copy link
Member Author

Choose a reason for hiding this comment

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

Since we didn't "unset" the transction (clean up) after it flushed, it produced a weird debug output if you switched tabs that the active transaction was "unset" because of page going to background.

@@ -542,6 +536,11 @@ export class Tracing implements Integration {
const startTime = Tracing._msToSec(entry.startTime as number);
const duration = Tracing._msToSec(entry.duration as number);

if (transactionSpan.op === 'navigation' && timeOrigin + startTime < transactionSpan.startTimestamp) {
logger.log('[Tracing] Discarded performance entry because of navigation');
Copy link
Contributor

Choose a reason for hiding this comment

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

Was useful for debugging.

  • Do we expect this to cause a lot of pollution in the console in SPAs?
  • Is there enough info if we need to debug a problem? We logged the entry when manually testing this.

Just want to gauge the noise/signal ratio here.

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 point, I think we can remove this.
For now, my premise was, since this integration is anyway very beta I thought the more output the better.

Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
logger.log('[Tracing] Discarded performance entry because of navigation');
logger.log('[Tracing] Discarded performance entry because of navigation', entry);

Could we do that? If we discard an entry, will be good to know what it was instead of just seeing a number of log messages that are equal in the console.

Copy link
Contributor

Choose a reason for hiding this comment

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

Talked outside of GH and decided to remove it for now.

We can always add it back if needed.

@rhcarvalho
Copy link
Contributor

Failed Travis build:

https://travis-ci.com/getsentry/sentry-javascript/jobs/296533185

Build output (truncated)
@sentry/apm: $ jest
@sentry/apm: PASS test/span.test.ts
@sentry/apm: PASS test/tracing.test.ts
@sentry/apm: PASS test/hub.test.ts
@sentry/apm: -------------------|----------|----------|----------|----------|-------------------|
@sentry/apm: File               |  % Stmts | % Branch |  % Funcs |  % Lines | Uncovered Line #s |
@sentry/apm: -------------------|----------|----------|----------|----------|-------------------|
@sentry/apm: All files          |    42.09 |    20.19 |    40.26 |    40.63 |                   |
@sentry/apm:  src               |    83.61 |    42.86 |    91.67 |    82.61 |                   |
@sentry/apm:   hubextensions.ts |    65.38 |       50 |       75 |    65.38 |... 28,59,60,64,65 |
@sentry/apm:   index.ts         |      100 |      100 |      100 |      100 |                   |
@sentry/apm:   span.ts          |    87.64 |    35.71 |       95 |     86.9 |... 88,294,296,298 |
@sentry/apm:  src/integrations  |    23.33 |    11.84 |    16.98 |    22.35 |                   |
@sentry/apm:   express.ts       |    15.38 |        0 |        0 |    13.51 |... 36,137,138,140 |
@sentry/apm:   index.ts         |      100 |      100 |      100 |      100 |                   |
@sentry/apm:   tracing.ts       |    23.35 |    12.16 |    23.08 |    23.11 |... 28,830,836,849 |
@sentry/apm: -------------------|----------|----------|----------|----------|-------------------|
@sentry/apm: Test Suites: 3 passed, 3 total
@sentry/apm: Tests:       31 passed, 31 total
@sentry/apm: Snapshots:   0 total
@sentry/apm: Time:        4.506s
@sentry/apm: Ran all test suites.
@sentry/apm: Jest did not exit one second after the test run has completed.
@sentry/apm: This usually means that there are asynchronous operations that weren't stopped in your tests. Consider running Jest with `--detectOpenHandles` to troubleshoot this issue.
No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#build-times-out-because-no-output-was-received
The build has been terminated

Debugging it with --detectOpenHandles (and running only apm tests, will drop the commit later)

@rhcarvalho
Copy link
Contributor

Tests ran but job is still hanging: https://travis-ci.com/getsentry/sentry-javascript/jobs/296559174

...
@sentry/apm: Test Suites: 3 passed, 3 total
@sentry/apm: Tests:       31 passed, 31 total
@sentry/apm: Snapshots:   0 total
@sentry/apm: Time:        4.614s
@sentry/apm: Ran all test suites.

Nothing helpful from --detectOpenHandles so far.

@rhcarvalho
Copy link
Contributor

For the record, there's an open issue in jest related to what we're seeing now:

jestjs/jest#7287

Wondering if anything changed in our end recently that would trigger that.

HazAT and others added 6 commits March 10, 2020 17:32
Also remove offset time calculations since everything is based on timeOrigin
Document the argument using the same format used in microsoft/TypeScript
code base.
Co-Authored-By: Rodolfo Carvalho <rodolfo.carvalho@sentry.io>
@getsentry-bot
Copy link
Contributor

getsentry-bot commented Mar 10, 2020

Messages
📖

@sentry/browser bundle gzip'ed minified size: (ES5: 16.8545 kB) (ES6: 15.8916 kB)

📖 ✅ TSLint passed

Generated by 🚫 dangerJS against caa5aa0

@rhcarvalho
Copy link
Contributor

Removing the empty tests in bbf54ad seemed to have fixed it (tested locally).

We may reintroduce this later on-demand. For now, reduce noise.
@rhcarvalho
Copy link
Contributor

All green in the relevant parts of https://travis-ci.com/github/getsentry/sentry-javascript/builds/152669617

@rhcarvalho
Copy link
Contributor

Only CI failure is integration tests in browserstack https://travis-ci.com/github/getsentry/sentry-javascript/jobs/296606639

Seems like just a flake again.... do we even have tracing integration tests?!

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.

None yet

4 participants