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

controller: fix limiter cannot work well in high concurrency scenario (#8436) #8438

Merged

Conversation

ti-chi-bot
Copy link
Member

This is an automated cherry-pick of #8436

What problem does this PR solve?

Issue Number: Close #8435

What is changed and how does it work?

controller: Fix limiter not functioning well in high concurrency scenarios
- In high concurrency scenarios, time may appear rollback because the `now` value passed from outside. high mutext completion leading to more non-sequential execution orders.
- Time rollback allows advancing more tokens, which can cause the issue. even result in no limit for the controller.
- Fix the problem by avoiding time rollback; instead of acquiring time again within the lock to fix it, as this might incur high costs when frequently acquiring time.

Check List

Tests

  • Unit test
  • Integration test
  • Manual test (add detailed scripts or steps below)
Concurrency reserveN limit Need Wait Actually QPS Actually RU_COST Pass
10000 1000 4000000 2.500s 4000.00 4000000.00
5000 1000 4000000 1.250s 4001.00 4001000.00
3840 1000 4000000 959.974ms 4004.00 4004000.00
1000 1000 4000000 249.516ms 4003.00 4003000.00
1000 200 4000000 49.280ms 19995.00 3999000.00
1000 5000 4000000 1.251s 799.00 3995000.00
10000 50 400000 1.250s 8004.00 400200.00
5000 50 400000 624.458ms 8008.00 400400.00
3840 50 400000 479.007ms 7999.00 399950.00
1000 50 400000 124.289ms 8006.00 400300.00
500 50 400000 61.506ms 8006.00 400300.00
200 50 400000 24.196ms 7997.00 399850.00
100 50 400000 12.593ms 8006.00 400300.00
1000 10 400000 24.047ms 39988.00 399880.00
1000 250 400000 624.222ms 1599.00 399750.00
10000 500 400000 12.515s 799.00 399500.00
5000 500 400000 6.257s 798.00 399000.00
3840 500 400000 4.804s 798.00 399000.00
1000 500 400000 1.250s 798.00 399000.00
1000 100 200000 500.261ms 2001.00 200100.00
1000 100 400000 250.175ms 4003.00 400300.00

real workload
image

Release note

None.

@ti-chi-bot ti-chi-bot added approved dco-signoff: yes Indicates the PR's author has signed the dco. labels Jul 25, 2024
@ti-chi-bot ti-chi-bot added lgtm release-note-none Denotes a PR that doesn't merit a release note. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. type/cherry-pick-for-release-8.1 This PR is cherry-picked to release-8.1 from a source PR. labels Jul 25, 2024
@ti-chi-bot ti-chi-bot bot added the approved label Jul 25, 2024
Copy link
Contributor

ti-chi-bot bot commented Jul 25, 2024

[APPROVALNOTIFIER] This PR is APPROVED

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

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 added the cherry-pick-approved Cherry pick PR approved by release team. label Jul 25, 2024
@ti-chi-bot ti-chi-bot bot merged commit f1a9096 into tikv:release-8.1 Jul 25, 2024
22 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved cherry-pick-approved Cherry pick PR approved by release team. 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/L Denotes a PR that changes 100-499 lines, ignoring generated files. type/cherry-pick-for-release-8.1 This PR is cherry-picked to release-8.1 from a source PR.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants