-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[8.15](backport #40699) Add asynchronous ACK handling to S3 and SQS inputs #41248
Conversation
Modify SQS ingestion to listen for ACKs asynchronously so that input workers can keep reading new objects after a previous one has been published, instead of blocking on full upstream ingestion. This addresses the bottleneck where ingesting many small objects is slow as each one waits for a full ingestion round trip. With a default configuration, SQS queues with many small objects are now ingested up to 60x faster. (cherry picked from commit d2867fd) # Conflicts: # go.sum # x-pack/filebeat/input/awss3/input_benchmark_test.go # x-pack/filebeat/input/awss3/s3_objects.go # x-pack/filebeat/input/awss3/sqs_s3_event_test.go
Cherry-pick of d2867fd has failed:
To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally |
This pull request doesn't have a |
Not sure we should backport this to 8.15. |
When/if we merge the backport is more a question of how long we want it to soak or if we want to do additional testing before release. This is a performance bugfix not a new feature so at a high level we could backport it. |
Agreed. it's touching a lot of files and not obvious that a user is in anyway blocked. I suggest avoid backport as long as possible. |
This pull request is now in conflicts. Could you fix it? 🙏
|
Modify SQS ingestion to listen for ACKs asynchronously so that input workers can keep reading new objects after a previous one has been published, instead of blocking on full upstream ingestion. This addresses the bottleneck where ingesting many small objects is slow as each one waits for a full ingestion round trip.
Checklist
I have made corresponding change to the default configuration filesCHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.How to test this PR locally
This can best be tested by ingesting data from a live S3 or SQS queue. The scenario that most highlights the changed performance is ingesting many small individual objects.
Related issues
aws-s3
input workers shouldn't wait for objects to be fully ingested before starting the next object #39414This is an automatic backport of pull request Add asynchronous ACK handling to S3 and SQS inputs #40699 done by Mergify.