Skip to content

*: add simplified low latency performance mode#4

Draft
asddongmen wants to merge 37 commits into
0713-low-latency-basefrom
agent/simplify-low-latency-mode
Draft

*: add simplified low latency performance mode#4
asddongmen wants to merge 37 commits into
0713-low-latency-basefrom
agent/simplify-low-latency-mode

Conversation

@asddongmen

@asddongmen asddongmen commented Jul 21, 2026

Copy link
Copy Markdown
Owner

What problem does this PR solve?

Issue Number: close pingcap#5705

TiCDC's default timestamp propagation favors throughput and adds avoidable latency for latency-sensitive deployments. SchemaStore can also temporarily cap a dispatcher's resolved-ts; relying only on the next EventStore notification delays recovery.

What is changed and how it works?

  • Add opt-in performance-mode = "low-latency"; throughput remains the default.
  • Advance LogPuller resolved-ts without the normal batching interval in low-latency mode.
  • Shorten downstream dispatcher and Maintainer watermark reporting, and trigger checkpoint calculation when a newer watermark arrives.
  • Report the maximum paired per-node resolved-ts lag to avoid an extra sampling-cycle artifact.
  • Serialize normal dispatcher scan ownership with a short-lock state machine. Bounded worker queues remain nonblocking and duplicate notifications coalesce; ready, handshake, range calculation, resolved-ts, syncpoint, scan, and send actions run under worker ownership.
  • In low-latency mode only, collect schema-blocked dispatchers by keyspace and poll the applied SchemaStore frontier every 50ms. A dispatcher is retried after the frontier advances; a full worker queue retains the blocked entry for the next tick. No SchemaStore notifier or unlimited queue is added.

Check List

Tests

  • Unit tests
  • Focused race tests
  • Manual build and formatting checks

Questions

Will it cause performance regression or break compatibility?

Throughput mode remains the default and does not start schema-blocked polling. Low-latency mode intentionally increases control-message frequency and adds one 50ms keyspace-level check loop; blocked dispatchers consume registry memory until resumed or removed.

Do you need to update user documentation, design documentation or monitoring documentation?

Yes. Document the performance mode and its latency/resource trade-off before GA.

Release note

Add an opt-in low-latency performance mode with faster resolved-ts and checkpoint propagation.

Replace the periodic schema-capped scan retry with applied SchemaStore notifications. Serialize dispatcher scan scheduling with a short-lock state machine and coalesce worker continuations without dropping queued work.
Keep no-DML/no-DDL resolved notifications out of the scan worker queue while preserving dispatcher scan ownership. Gate continuation and schema-blocked recovery on low-latency mode, and cover queue-full recovery with a dropped-task metric.
@asddongmen
asddongmen force-pushed the agent/simplify-low-latency-mode branch from 1f97b0b to 52a0082 Compare July 25, 2026 10:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants