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

*: support coprocessor cache for paging protocol #35787

Merged
merged 9 commits into from
Jul 1, 2022

Conversation

tiancaiamao
Copy link
Contributor

What problem does this PR solve?

Issue Number: close #35786

Problem Summary:

What is changed and how it works?

The paging protocol breaks coprocessor cache (when I enable paging), now I'd like to bring it back.

It works like this:

  1. For coprocessor paging request, the cache key will add an extra 'paging=1' byte.

  2. After receiving the cop paging response, the cache value will store both the Data and the paging Range.

  3. When the cop paging request hit cache, it will recover both Data and Range information.

  4. So after the handleCopTask, it update the paging range to the next one.

In a work, each of the paging request is cached and reused seperately.

Check List

Tests

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

Side effects

  • Performance regression: Consumes more CPU
  • Performance regression: Consumes more Memory
  • Breaking backward compatibility

Documentation

  • Affects user behaviors
  • Contains syntax changes
  • Contains variable changes
  • Contains experimental features
  • Changes MySQL compatibility

Release note

Please refer to Release Notes Language Style Guide to write a quality release note.

None

@ti-chi-bot
Copy link
Member

ti-chi-bot commented Jun 28, 2022

[REVIEW NOTIFICATION]

This pull request has been approved by:

  • XuHuaiyu
  • xhebox

To complete the pull request process, please ask the reviewers in the list to review by filling /cc @reviewer in the comment.
After your PR has acquired the required number of LGTMs, you can assign this pull request to the committer in the list by filling /assign @committer in the comment to help you merge this pull request.

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

Reviewer can indicate their review by submitting an approval review.
Reviewer can cancel approval by submitting a request changes review.

@ti-chi-bot ti-chi-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. do-not-merge/needs-triage-completed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Jun 28, 2022
@tiancaiamao tiancaiamao marked this pull request as ready for review June 28, 2022 08:13
@ti-chi-bot ti-chi-bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jun 28, 2022
@tiancaiamao
Copy link
Contributor Author

/run-check-issue-triage-complete

@sre-bot
Copy link
Contributor

sre-bot commented Jun 28, 2022

@ti-chi-bot ti-chi-bot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Jun 29, 2022
@ti-chi-bot ti-chi-bot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 30, 2022
@ti-chi-bot ti-chi-bot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 1, 2022
@ti-chi-bot ti-chi-bot added the status/LGT1 Indicates that a PR has LGTM 1. label Jul 1, 2022
@tiancaiamao
Copy link
Contributor Author

One compatibility issue I found is that in the old setting, CheckResponseAdmission will cache coprocessor request whose ProcessTime is longer than 5ms

While in the paging protocol, for many cases, the segmented page request takes less than 5ms and is thus not cached.

@xhebox
Copy link
Contributor

xhebox commented Jul 1, 2022

One compatibility issue I found is that in the old setting, CheckResponseAdmission will cache coprocessor request whose ProcessTime is longer than 5ms

While in the paging protocol, for many cases, the segmented page request takes less than 5ms and is thus not cached.

I think it is transparent to users. So it is only a behavior change for us. Maybe we could use two different timing parameters for stream/paging.

copy(end, cacheValue.PageEnd)
}
// When paging protocol is used, the response key range is part of the cache data.
resp.pbResp.Range = &coprocessor.KeyRange{
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we set resp.pbResp.Range = nil when cacheValue.PageStart/PageEnd == nil?

@ti-chi-bot ti-chi-bot added status/LGT2 Indicates that a PR has LGTM 2. and removed status/LGT1 Indicates that a PR has LGTM 1. labels Jul 1, 2022
@XuHuaiyu
Copy link
Contributor

XuHuaiyu commented Jul 1, 2022

/merge

@ti-chi-bot ti-chi-bot added the status/can-merge Indicates a PR has been approved by a committer. label Jul 1, 2022
@XuHuaiyu
Copy link
Contributor

XuHuaiyu commented Jul 1, 2022

/merge cancel

@ti-chi-bot ti-chi-bot removed the status/can-merge Indicates a PR has been approved by a committer. label Jul 1, 2022
@tiancaiamao
Copy link
Contributor Author

/run-check_dev_2

@tiancaiamao
Copy link
Contributor Author

/merge

@ti-chi-bot
Copy link
Member

This pull request has been accepted and is ready to merge.

Commit hash: f7f8f88

@ti-chi-bot ti-chi-bot added the status/can-merge Indicates a PR has been approved by a committer. label Jul 1, 2022
@tiancaiamao
Copy link
Contributor Author

/run-check_dev_2

@ti-chi-bot ti-chi-bot merged commit b71a23b into pingcap:master Jul 1, 2022
@tiancaiamao tiancaiamao deleted the cop-paging branch July 1, 2022 10:47
@sre-bot
Copy link
Contributor

sre-bot commented Jul 1, 2022

TiDB MergeCI notify

🔴 Bad News! New failing [2] after this pr merged.
These new failed integration tests seem to be caused by the current PR, please try to fix these new failed integration tests, thanks!

CI Name Result Duration Compare with Parent commit
idc-jenkins-ci-tidb/integration-common-test 🟥 failed 1, success 10, total 11 24 min New failing
idc-jenkins-ci-tidb/common-test 🟥 failed 1, success 11, total 12 12 min New failing
idc-jenkins-ci/integration-cdc-test 🟢 all 35 tests passed 27 min Existing passed
idc-jenkins-ci-tidb/tics-test 🟢 all 1 tests passed 6 min 41 sec Existing passed
idc-jenkins-ci-tidb/sqllogic-test-2 🟢 all 28 tests passed 5 min 42 sec Existing passed
idc-jenkins-ci-tidb/integration-ddl-test 🟢 all 6 tests passed 5 min 31 sec Existing passed
idc-jenkins-ci-tidb/sqllogic-test-1 🟢 all 26 tests passed 5 min 12 sec Existing passed
idc-jenkins-ci-tidb/integration-compatibility-test 🟢 all 1 tests passed 3 min 21 sec Existing passed
idc-jenkins-ci-tidb/mybatis-test 🟢 all 1 tests passed 3 min 11 sec Existing passed
idc-jenkins-ci-tidb/plugin-test 🟢 build success, plugin test success 4min Existing passed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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. status/can-merge Indicates a PR has been approved by a committer. status/LGT2 Indicates that a PR has LGTM 2.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Fix cop cache for paging protocol
7 participants