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: Support TSO RPC Parallelizing #8432

Closed
2 of 3 tasks
MyonKeminta opened this issue Jul 23, 2024 · 0 comments · Fixed by #8633
Closed
2 of 3 tasks

client: Support TSO RPC Parallelizing #8432

MyonKeminta opened this issue Jul 23, 2024 · 0 comments · Fixed by #8633
Labels
type/development The issue belongs to a development tasks

Comments

@MyonKeminta
Copy link
Contributor

MyonKeminta commented Jul 23, 2024

Development Task

We used to find that in some OLTP workloads where the QPS is high and the queries are simple, the TSO Wait duration usually become a significant portion of the total duration of queries. In TiDB, TSO loading is already made concurrent with some other works such as compiling. In cases that the queries are simple, it would be hard to further optimize it by making it concurrent with more phases of the SQL execution. But we found a practical way to optimize it is to do it from the TSO client.

Currently, a TSO client object has a goroutine that collects GetTS (and GetTSAsync) calls (tsoRequests) as a batch, send it to PD, wait for the response, and dispatch the results to these tsoRequests, serially. As a result, each GetTS calls may need to spend up to 1x TSO RPC time to wait for being collected to the next batch.

Considering the case that PD's TSO allocator is not the bottle neck and can deal with more TSO requests (so that the majority part of TSO RPC's time cost is on the network), we find that it's possible to start collecting the next batch and send it before receiving the response of the previous batch. So that each GetTS call needs to wait for less time to be batched, and gets a shorter total duration.

So this is an approach that reduces the duration of GetTS & GetTSAsync - Wait at the expense of higher TSO RPC OPS and higher pressure to PD. It's not suitable to be enabled by default, but we can provide such an option when the TSO Wait duration becomes a problem.

Subtasks

Side changes:

@MyonKeminta MyonKeminta added the type/development The issue belongs to a development tasks label Jul 23, 2024
ti-chi-bot bot added a commit that referenced this issue Jul 29, 2024
…g and metrics reporting code (#8433)

ref #8432

client: Merge the two tsoStream types to reuse the same error handling and metrics reporting code

This commit merges the two `xxxTSOStream` types so that the error handling and metrics reporting logic for PD server deployment and TSO service deployment can be reused.

Signed-off-by: MyonKeminta <MyonKeminta@users.noreply.github.com>

Co-authored-by: ti-chi-bot[bot] <108142056+ti-chi-bot[bot]@users.noreply.github.com>
ti-chi-bot bot added a commit that referenced this issue Sep 14, 2024
ref #8432

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

Signed-off-by: MyonKeminta <MyonKeminta@users.noreply.github.com>

Co-authored-by: ti-chi-bot[bot] <108142056+ti-chi-bot[bot]@users.noreply.github.com>
@ti-chi-bot ti-chi-bot bot closed this as completed in 642f0e9 Sep 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/development The issue belongs to a development tasks
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant