RemoteControlledSampler.sample() is a bottleneck

[yborovikov]

Requirement

Tracing should not be a bottleneck in multithreaded apps.

Problem - what in Jaeger blocks you from solving the requirement?

RemoteControlledSampler.sample() is synchronized.

This is causing a major slowdown in multithreaded applications:

Proposal - what do you suggest to solve the problem or improve the existing situation?

1. Remove unneeded synchronization.
2. Synchronize on non-public objects (instead of this or .class) where synchronization is unavoidable.
3. Clean up .equals() - avoid synchronized blocks (and remove the read locks?)
4. Explain the need for every remaining synchronization (in the code comments).

Any open questions to address

What is the purpose of RemoteControlledSampler.getLock()? Some JavaDoc would be helpful there.

[jpkrohling]

Based on the package name, looks like you are using an older version of the client. But I expect the same to happen with the latest versions, as this hasn't changed much, if at all.

In any case: we are planning on doing some performance measurements in the next couple of months with @gsoria and would appreciate any inputs you might have.

The first step is certainly to come up with a set of JMH scenarios representing the real-world usage of the client. The one that you described should certainly be part of it, so, if you are able to build a JMH test already, this would be highly appreciated.

Once we have that, we'll be able to measure the performance and assess the impact of the improvements.