Next perf steps next gen pipeline
- Dominant language
- Java
- Stars
- 14.9k
- Forks
- 3.5k
- Avg merge
- 1d 4h
- Merged PRs (30d)
- 88
Description
This ticket is a medium to long term design goal. While the next gen pipeline is much faster than the old one, the SynchronousQueue at its heart is still a choke point.
There are probably options out there that could remove this choke point. The best idea I currently have is to couple the workers to the inputs directly.
An alternative idea would be to switch from a SynchronousQueue to a work stealing queue (along the lines of what Java's Fork Join Pool does) to reduce contention even further.
One other idea (which may be the most practical) would be to allow inputs to send batches of events across the queue in a single operation (sending an Array of events instead of a single event). That would probably reduce contention to a practically negligible amount.
The impact here is really not knowable without doing it, so I'm labeling this as high hanging fruit.
Contributor guide
Research direction
Start by profiling the next gen pipeline around its SynchronousQueue choke point and read the existing worker and input flow. Compare direct worker coupling, a Java Fork/Join-style work-stealing queue, and batching arrays of events across the queue. Done requires a chosen design implemented and measured to reduce contention without regressing pipeline behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- backend, performance
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100