-
Notifications
You must be signed in to change notification settings - Fork 214
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
SendBatch: Don't start goroutines #232
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## master #232 +/- ##
==========================================
- Coverage 70.30% 70.30% -0.01%
==========================================
Files 27 27
Lines 3718 3721 +3
==========================================
+ Hits 2614 2616 +2
+ Misses 989 988 -1
- Partials 115 117 +2
☔ View full report in Codecov by Sentry. |
b980066
to
cd1536b
Compare
Testing shows this didn't affect performance, so I think this is worth merging because it simplifies thinking about the cost of a SendBatch. |
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.
The idea behind this makes sense to me, although I do see concern with the potential slowdown because we are doing this sequentially. But having the resource usage being more predictable (and less expensive with less goroutines) seems worthwhile. Other than the comment I left, LGTM.
Instead of starting goroutines we can queue each region server's collection of RPCs and only after queueing them all wait for all responses. We get a similar amount of parallelism, the only potential slow down is that we can't queue one region server's RPCs until the previous is able to be queued. By not starting goroutines, the resource usage of SendBatch is more predictable. And not starting goroutines is likely to be less expensive overall.
Instead of starting goroutines we can queue each region server's collection of RPCs and only after queueing them all wait for all responses. We get a similar amount of parallelism, the only potential slow down is that we can't queue one region server's RPCs until the previous is able to be queued.
By not starting goroutines, the resource usage of SendBatch is more predictable. And not starting goroutines is likely to be less expensive overall.
This change also adds a new metric for number of splits that occur in SendBatch.