elastic / elastic/logstash

Next perf steps next gen pipeline

Open
#4,323 2 comments 0 reactions 0 assignees View on GitHub
design enhancement high hanging fruit
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.