Non-blocking UUID generation for Spans

[Andrevmatias]

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 is 0 or null. This creates a lot of UUIDs that I think are not even necessary.

Solution Brainstorm

• Allow to set a non-blocking UUID generation fo Spans on Sentry initialization options
• Expose the UUID generation method as a spring component/service so it can be overwritten
• Create UUIDs just for the events that are effectively sent to Sentry
• Allow to disable instrumentation completely through configuration without disabling sending other types of events.

┆Issue is synchronized with this Jira Improvement by Unito

[adinauer]

Hello @Andrevmatias thanks for opening this issue. We'll add this to the backlog but can't say when we'll get to it.

[kozaxinan]

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.

[markushi]

In theory this should be straightforward:

• Instead of generating the UUIDs in the constructor, lazily evaluate them (so they get actually generated at protocol serialization time), and use object references (like we do already for SpanId)

To consider:

• equals methods
• toString()

[Angelodaniel]

Hey Team, it would really help to have reduced impact on performance from the sentry library. Is there any update on this? cc @markushi

[kahest]

@Angelodaniel thx for the ping, we'll revisit prio for this

[stefanosiano]

@lbloder Can you have a look at this?