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?

[adinauer]

Reminder to check which improvements make sense to port to v7

[lbloder]

Hi @Andrevmatias, @kozaxinan,
I'm currently testing some optimizations for UUID Generation, could you tell me which Android/Java Version you're using?

@kozaxinan from which android version does your profile chart come from?

I'm asking because apparently UUID.toString() has pretty bad performance on Java 8 and below. Java 9 and upwards should be a lot faster by default.

[kozaxinan]

Our minimum API is 23. I used a device with API 34 for this.

[Andrevmatias]

We are using Java 17. We implemented the Sentry instrumentation only because we upgraded the JDK from 8. We are aware of the Java 8 UUID problems.

Our main problem is that our software does a lot of operations per second and all of them are generating UUIDs now. Most of the times, needlessly.

[adinauer]

Thanks @Andrevmatias we're currently testing some improvements to speed up the ID generation.

[adinauer]

We have just released 8.0.0-beta.2 of the Java SDK, which improves ID generation. If you decide to give it a try, feedback would be great.