Език: Български
Fighting the round trip
Every database request pays a toll: the trip to the server and back. On a fast network you barely notice it. Across zones or regions, the trip costs far more than the work itself. This talk follows how go-redis, the official Go client for Redis, learned to pay that toll less often.
A database client is a logistics problem. Requests are shipments, the network is the road, and every round trip is a truck that drives to the server and back. The server answers in microseconds. The road is what costs you.
The easy fix is to move the server closer. Often you can't: the data is replicated across regions, the cloud decides where it runs, or many services in different places share it. When the road stays long, the client has to change how it ships.
Lets follow the evolution of go-redis, step by step:
- a pool of connections, one request per trip;
- automatic batching, where many callers share one trip;
- a multiplexed connection, where one connection sends new requests while earlier answers are still coming back;
- batches that stay together on that shared multiplexed connection.
Each step fixed the limit of the one before it.
Key takeaways:
- Why round-trip time, not server speed, limits most clients.
- How batching and a multiplexed connection each cut round trips, and the limit each one hits.
- How to choose the right technique for your network and workload.
Audience:
Developers who maintain or use any database or network client. No Redis knowledge needed.