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

backend, net: reduce memory allocation in forwarding packets #394

Merged
merged 7 commits into from
Nov 6, 2023

Conversation

djshow832
Copy link
Collaborator

@djshow832 djshow832 commented Nov 2, 2023

What problem does this PR solve?

Issue Number: close #381

Problem Summary:

  • We can further avoid memory allocation through ForwardUntil for more kinds of packets, such as the OK packet.
  • We don't need the affected rows and insert ids in the OK packets, while they are parsed and allocated memory.

What is changed and how it works:

  • Use ForwardUntil in forwardPrepareCmd, forwardQueryCmd, and forwardResultSet.
  • Support forwarding long data (length > 16MB) in ForwardUntil.
  • Only return the server status in handleOKPacket and ignore other fields.
  • Do not flush the data every time in load local infile because we have a fixed buffer anyway.

Check List

Tests

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

Performance tests:

  • The benchmark result of BenchmarkForwardUntil is close to BenchmarkForwardWithReadWrite when loops<=10 but it becomes much better when loops>100.
  • QPS of oltp_point_select is from 66305 to 67634. The effect is very little but it's better anyway.

Notable changes

  • Has configuration change
  • Has HTTP API interfaces change
  • Has tiproxyctl change
  • Other user behavior changes

Release note

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

None

@djshow832 djshow832 changed the title backend, net: Use more ForwardUntil to reduce memory allocation backend, net: reduce memory allocation in forwarding packets Nov 2, 2023
@djshow832 djshow832 marked this pull request as ready for review November 2, 2023 10:11
@djshow832 djshow832 marked this pull request as draft November 3, 2023 00:43
@djshow832 djshow832 marked this pull request as ready for review November 3, 2023 00:58
@djshow832
Copy link
Collaborator Author

/retest

@ti-chi-bot ti-chi-bot bot removed the lgtm label Nov 6, 2023
Copy link

ti-chi-bot bot commented Nov 6, 2023

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: xhebox

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 added the lgtm label Nov 6, 2023
Copy link

ti-chi-bot bot commented Nov 6, 2023

[LGTM Timeline notifier]

Timeline:

  • 2023-11-06 07:32:29.737475939 +0000 UTC m=+3456747.324586068: ☑️ agreed by xhebox.
  • 2023-11-06 07:32:36.969160283 +0000 UTC m=+3456754.556270429: ✖️🔁 reset by xhebox.
  • 2023-11-06 07:52:17.466692554 +0000 UTC m=+3457935.053802684: ☑️ agreed by xhebox.

@ti-chi-bot ti-chi-bot bot merged commit 37c4701 into pingcap:main Nov 6, 2023
9 checks passed
@djshow832 djshow832 deleted the optimize_select branch November 6, 2023 08:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Performance gap between TiProxy and HAProxy grows as the dataset size grows
2 participants