Skip to content
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

client: Make tsoStream receives asynchronously #8483

Merged
merged 26 commits into from
Sep 14, 2024

Conversation

MyonKeminta
Copy link
Contributor

@MyonKeminta MyonKeminta commented Aug 2, 2024

What problem does this PR solve?

Issue Number: Ref #8432

What is changed and how does it work?

client: Make tsoStream receives asynchronously. This makes it possible to allow the tsoDispatcher send multiple requests and wait for their responses concurrently. 

Check List

Tests

  • Unit test
  • Integration test
  • Manual test (add detailed scripts or steps below)
  • No code

Code changes

Side effects

  • Possible performance regression
  • Increased code complexity
  • Breaking backward compatibility

Related changes

Release note

None.

Copy link
Contributor

ti-chi-bot bot commented Aug 2, 2024

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@ti-chi-bot ti-chi-bot bot added release-note-none Denotes a PR that doesn't merit a release note. do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. dco-signoff: yes Indicates the PR's author has signed the dco. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. labels Aug 2, 2024
@ti-chi-bot ti-chi-bot bot added size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. and removed size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. labels Aug 7, 2024
Signed-off-by: MyonKeminta <[email protected]>
Signed-off-by: MyonKeminta <[email protected]>
Signed-off-by: MyonKeminta <[email protected]>
Signed-off-by: MyonKeminta <[email protected]>
Signed-off-by: MyonKeminta <[email protected]>
Signed-off-by: MyonKeminta <[email protected]>
Signed-off-by: MyonKeminta <[email protected]>
Copy link

codecov bot commented Sep 4, 2024

Codecov Report

Attention: Patch coverage is 81.14754% with 46 lines in your changes missing coverage. Please review.

Project coverage is 77.61%. Comparing base (098b802) to head (5314485).
Report is 1 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #8483      +/-   ##
==========================================
- Coverage   77.66%   77.61%   -0.05%     
==========================================
  Files         474      474              
  Lines       61898    62033     +135     
==========================================
+ Hits        48072    48148      +76     
- Misses      10283    10340      +57     
- Partials     3543     3545       +2     
Flag Coverage Δ
unittests 77.61% <81.14%> (-0.05%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

@MyonKeminta MyonKeminta marked this pull request as ready for review September 4, 2024 09:49
@MyonKeminta MyonKeminta changed the title [WIP] client: Make tsoStream receives asynchronously. client: Make tsoStream receives asynchronously. Sep 4, 2024
@ti-chi-bot ti-chi-bot bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Sep 4, 2024
@MyonKeminta MyonKeminta changed the title client: Make tsoStream receives asynchronously. client: Make tsoStream receives asynchronously Sep 5, 2024
client/tso_batch_controller.go Outdated Show resolved Hide resolved
client/tso_dispatcher.go Outdated Show resolved Hide resolved
client/tso_stream.go Show resolved Hide resolved
Signed-off-by: MyonKeminta <[email protected]>
@cfzjywxk
Copy link

cfzjywxk commented Sep 6, 2024

@JmPotato @lhy1024 PTAL, thx

@@ -0,0 +1,333 @@
// Copyright 2024 TiKV Project Authors.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to add bench for it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean mocking the internal implementation of the stream and benching the overhead of the tsoStream layer?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to add a bench to compare the performance change before and after introducing this pr.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll have a try on this


const invalidStreamID = "<invalid>"

// TODO: Pass a context?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will we pass it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I forgot this. I'll have a try.

})

// A large-enough capacity to hold maximum concurrent RPC requests. In our design, the concurrency is at most 16.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will it be changed in the future?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have such plan. As the more concurrent RPC there is, the less we can benefit from each additional concurrent RPC, it's not a good idea to allow too many concurrent RPCs for each stream. In our current plan, 16 is the maximum.

@MyonKeminta
Copy link
Contributor Author

MyonKeminta commented Sep 12, 2024

@lhy1024 I've done some benchmarks with the stream implemented by channels internally to show the overhead of tsoStream and tsoDispatcher. Please see if it's acceptable.

Before this PR: (code in #8618 , which is branched from the merge-base of this PR and master)

goos: linux
goarch: amd64
pkg: github.com/tikv/pd/client
cpu: Intel(R) Xeon(R) Silver 4214R CPU @ 2.40GHz
BenchmarkTSODispatcherHandleRequests-28           140149              7508 ns/op
BenchmarkTSOStreamSendRecv-28                    2788069               425.8 ns/op
PASS
ok      github.com/tikv/pd/client       2.796s

This PR (bff9eae):

goos: linux
goarch: amd64
pkg: github.com/tikv/pd/client
cpu: Intel(R) Xeon(R) Silver 4214R CPU @ 2.40GHz
BenchmarkTSODispatcherHandleRequests-28           119170              9254 ns/op
BenchmarkTSOStreamSendRecv-28                     676719              1647 ns/op
PASS
ok      github.com/tikv/pd/client       3.276s

There are several microseconds of additional overhead in this PR.

Please see if this is acceptable.

If you feel good with it, let's consider merging #8618 before this PR.

@ti-chi-bot ti-chi-bot bot added needs-1-more-lgtm Indicates a PR needs 1 more LGTM. approved labels Sep 14, 2024
Copy link
Contributor

@lhy1024 lhy1024 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the rest LGTM

for !s.state.CompareAndSwap(streamStateIdle, streamStateClosing) {
switch state := s.state.Load(); state {
case streamStateIdle, streamStateSending:
// streamStateSending should switch to streamStateIdle very quickly. Spin until successfully setting to
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Spin?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. Considering that there won't be any blocking operation in streamStateSending state and the state won't last long, I think spinning here is better than writing another syncing operation here.

@ti-chi-bot ti-chi-bot bot added the lgtm label Sep 14, 2024
Copy link
Contributor

ti-chi-bot bot commented Sep 14, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: JmPotato, lhy1024

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@ti-chi-bot ti-chi-bot bot removed the needs-1-more-lgtm Indicates a PR needs 1 more LGTM. label Sep 14, 2024
Copy link
Contributor

ti-chi-bot bot commented Sep 14, 2024

[LGTM Timeline notifier]

Timeline:

  • 2024-09-14 07:03:22.710211923 +0000 UTC m=+685472.450635862: ☑️ agreed by JmPotato.
  • 2024-09-14 07:13:56.838181014 +0000 UTC m=+686106.578604946: ☑️ agreed by lhy1024.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved dco-signoff: yes Indicates the PR's author has signed the dco. lgtm release-note-none Denotes a PR that doesn't merit a release note. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants