-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Reduce blocking main thread during span logic #14067
Comments
Hello thanks for raising this and also digging into this problem! I think your proposed change looks reasonable. It's not needed to get a fresh timestamp on every filter. Are you interested in submitting a PR? |
Opened a PR for this! #14094 |
resolves #14067 Avoid calling `Date.now()` for each span in the span exporter. This should reduce blocking I/O.
A PR closing this issue has just been released 🚀This issue was referenced by PR #14094, which was included in the 8.36.0 release. |
Hi @theguacamoleking could you try the latest release of the JS SDK to see if the profiles look better? We've made some fixes since then. |
This issue has gone three weeks without activity. In another week, I will close it. But! If you comment or otherwise update it, I will reset the clock, and if you remove the label "A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀 |
Problem Statement
Hi there, I wanted to flag an issue where my deeper GraphQL queries take exponentially longer when using Sentry. This looks to be because Sentry logic ends up blocking the main thread
As you can see above, logic within @sentry/opentelemetry is taking up more than 50% of time on the main thread over the period of over 15s. With Sentry disabled, the same GraphQL request takes about 2 seconds.
Solution Brainstorm
System clock lookups
The following code is the worst offender
Specifically the
cutoff
assignment. I'd propose something like the following where there is only one system clock read for each call of_cleanupOldSpans
.The text was updated successfully, but these errors were encountered: