Clipper 8
- vCPU
- 4 × dedicated
- RAM
- 8 GB
- Storage
- 200 GB NVMe Gen4 SSD
- Transfer
- 20 TB
- IPv4 / IPv6
- 1 / /64 routed
Solution
Sub-10 ms API responses are a placement problem before they are a code problem. Physics puts a floor of about 1 ms per 100 km of fibre, so no amount of optimisation beats being in the wrong city. Deploy Clipper instances in the regions your users are in, keep the hot path free of cross-region calls, and measure at the 99th percentile rather than the mean.
| Resource | What you actually need |
|---|---|
| CPU | High-frequency dedicated cores; tail latency is a scheduling problem |
| RAM | 8–32 GB depending on working set |
| Disk | NVMe Gen4 |
| Network | Anycast-capable regions for a single global entry point |
Location is usually the decision that matters most for this workload — either because latency dominates, or because jurisdiction does.
Then deploy to those regions, not to the cheapest one.
High-frequency cores, and pin the process.
One cross-region database call erases every other optimisation.
Connection setup dominates short-request latency.
Averages hide exactly the requests your users complain about.
Under 1 ms of server time is achievable for simple handlers on dedicated cores. Total user-perceived latency is dominated by distance: roughly 1 ms per 100 km each way, so placement decides the outcome.
Yes, by routing each user to the nearest healthy instance without DNS propagation delay. It requires instances in several regions and is available in our anycast-capable locations.
Usually CPU steal time on shared cores, or garbage collection. Dedicated cores remove the first; the second is a code problem.