-
Notifications
You must be signed in to change notification settings - Fork 90
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
Batch events #175
Merged
Merged
Batch events #175
+830
−372
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
kate-osborn
requested changes
Aug 8, 2022
kate-osborn
approved these changes
Aug 10, 2022
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀
14bf07e
to
53313b7
Compare
654c33b
to
c729ee0
Compare
f5yacobucci
reviewed
Aug 15, 2022
f5yacobucci
reviewed
Aug 15, 2022
f5yacobucci
approved these changes
Aug 16, 2022
kate-osborn
approved these changes
Aug 16, 2022
Previously, the Gateway would handle one event (upserting or deleting a Kubernetes resource) at a time. This commit introduces event batching: multiple events (a batch) are handled at once. Batching is needed because, because typically handling an event (or multiple events at once) will result into reloading NGINX, which is the operation we want to minimize, for the following reasons: (1) A reload takes time - at least 200ms. The time depends on the size of the configuration including the number of TLS certs, available CPU cycles. (2) A reload can have side-effects for the data plane traffic. Now, when a new event comes, there are two cases: - If there is no event(s) currently being handled, the new event is handled immediately. - Otherwise, the new event will be saved for later handling. All saved events will be handled after the handling of the current event(s) finishes. Multiple saved events will be handled at once in one batch. Additional implementation notes: (a) The EventLoop was split into two parts: (1) The EventHandler, which is only responsible for handling a batch of events, without dealing with concurrency. (2) The stripped-down EventLoop, which is responsible for batching events and propagating batches to the EventHandler in a dedicated goroutine. (b) The ChangeProcessor was fixed, so that when multiple changes are captured (coming from a single batch) -- first, changes that cause data plane reconfiguration, followed by changes that do not cause reconfiguration -- in that case, the data plane will be reconfigured. Without the fix, the latter changes would prevent data plane from reconfiguring. Note that the bug only appeared when batching was added.
281e342
to
9501170
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Proposed changes
Previously, the Gateway would handle one event (upserting or deleting a
Kubernetes resource) at a time.
This PR introduces event batching: multiple events (a batch) are
handled at once.
Batching is needed because, because typically handling an event (or
multiple events at once) will result into reloading NGINX, which is
the operation we want to minimize, for the following reasons:
(1) A reload takes time - at least 200ms. The time depends on the size
of the configuration including the number of TLS certs, available CPU
cycles.
(2) A reload can have side-effects for the data plane traffic.
Now, when a new event comes, there are two cases:
handled immediately.
events will be handled after the handling of the current event(s)
finishes. Multiple saved events will be handled at once in one batch.
Additional implementation notes:
(a) The EventLoop was split into two parts:
(1) The EventHandler, which is only responsible for handling a batch of
events, without dealing with concurrency.
(2) The stripped-down EventLoop, which is responsible for batching events
and propagating batches to the EventHandler in a dedicated goroutine.
(b) The ChangeProcessor was fixed, so that when multiple changes are
captured (coming from a single batch) -- first, changes that cause
data plane reconfiguration, followed by changes that do not cause
reconfiguration -- in that case, the data plane will be reconfigured.
Without the fix, the latter changes would prevent data plane from
reconfiguring. Note that the bug only appeared when batching was added.