# Connection And Network Latency

Use this branch for slow connection establishment, disconnects, RPC-layer
latency, component-to-component delay, or bandwidth saturation.

## Separate The Phase

First determine whether the delay happens:

- before SQL reaches TiDB: DNS, TCP, TLS, proxy/load balancer, client pool, or
  authentication;
- during SQL execution: TiDB-to-TiKV/PD RPC, TiKV raft traffic, or application
  result transfer.

Do not use normal SQL execution metrics to claim the pre-SQL connection path is
healthy.

## Component Checks

- TiDB to TiKV: batch-client reconnect/unavailable/wait-connect duration,
  RPC-layer latency, slow-log RPC/backoff evidence, and node bandwidth limits.
- TiDB to PD: client failures and TSO RPC duration compared with PD server TSO
  handling duration.
- PD to PD: etcd peer RTT compared with WAL fsync and transaction handling.
- TiKV to TiKV: unreachable/send-queue evidence and commit duration compared
  with local append/apply duration.
- Client connection path: datasource/connection pool, target hostname, DNS,
  proxy/load balancer, TCP/TLS handshake, and TiDB accept/authentication timing.

## Interpretation

- Reconnect or unavailable evidence supports interruption, but an unreachable
  metric can also be caused by a blocked gRPC thread.
- Commit duration rising without local append/apply delay supports a remote
  quorum/network path.
- A normal server-side metric narrows the fault boundary; it does not identify
  DNS, proxy, network, or client-pool delay without direct evidence.
- Ask for only one routing identifier when the affected client entry point
  cannot be mapped from existing context.

Do not recommend keepalive, timeout, proxy, or load-balancing changes without
target-version verification and human review.