BatchSampleSender/StatisticalSampleSender slows thread handling down
- Dominant language
- Java
- Stars
- 9.5k
- Forks
- 2.3k
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 5
Description
**Danny Lade** ([Bug 54717](https://bz.apache.org/bugzilla//show_bug.cgi?id=54717&redirect=false)):
Because the BatchSampleSender/StatisticalSampleSender synchronizes the whole sampleOccurred() method it blocks the threads of each thread group.
The differences of the generate load can be seen using the DiskStoreSampleSender. In our case it was a factor of 3 faster. But this one could not be used striped therefore the request body is stored and will be send at the end (in our case several GB of data).
Although the AsynchSampleSender blocks several times on queue.offer() if the traffic could not be send fast enough to the client - which might also be a problem of sending the big request body too.
I suggest to decouple all sample senders from working threads, using a rather simple idea:
Store the (stripped) sample in a ConcurrentHashMap grouped by the current thread name and send it by one (ore more) worker thread(s) to the client.
There is no need to block the load generating threads doing their job.
OS: All
Contributor guide
Assessment
This issue has not been assessed yet.