Open Andrevmatias opened 5 months ago
Hello @Andrevmatias thanks for opening this issue. We'll add this to the backlog but can't say when we'll get to it.
Hi we also see lots of CPU usage for Span creation. UUID generation and then string manipulation takes some time. There are lots of spans during Android app creation and navigating that accumulate easily.
I support creating UUID in the background thread before sending idea. or any expensive operation about that part should be in the background thread.
In theory this should be straightforward:
SpanId
)To consider:
Hey Team, it would really help to have reduced impact on performance from the sentry library. Is there any update on this? cc @markushi
@Angelodaniel thx for the ping, we'll revisit prio for this
@lbloder Can you have a look at this?
Problem Statement
The UUID generation for Spans is made using
UUID.randomUUID()
deep within the library and can't be replaced easily.UUID.randomUUID()
can be a blocking method depending on the Java distribution and OS configurations and it's resulting in a lot of our threads being blocked, impairing the system performance. We don't have control over the servers were our system is installed.Also, the Spans and Transactions are created for every request regardless of whether it will be sent to Sentry. It occurs before the sampling process and is created even if
sentry.traces-sample-rate
is0
ornull
. This creates a lot of UUIDs that I think are not even necessary.Solution Brainstorm
┆Issue is synchronized with this Jira Improvement by Unito