Kernel settings are changeable; the distance between your server and your users is physics. Work out the latency floor from the map, understand why interconnection decides how close you get to it, and test from where the users actually are before committing.
Choosing a server location means picking the physical distance between your server and your users, and that distance sets a latency floor nothing in the software stack gets under. It is the one decision you cannot tune your way out of afterwards. Kernel settings, caches and codecs are all changeable; the distance between your server and your users is physics, and it sets a floor no amount of optimisation gets under. It is also the decision most often made by habit — Frankfurt because everyone picks Frankfurt — when three inputs would settle it properly: where the users are, which legal regime the data sits under, and what the path between the two actually looks like.
Light in fibre travels at roughly two-thirds of its speed in vacuum, about 200 km per millisecond. A round trip covers the distance twice, so:
minimum RTT (ms) ≈ distance (km) / 100
Real paths are longer than the straight line — cable routes follow coasts, borders and existing ducts — so multiply by 1.3 to 1.5 for a working estimate, then add a millisecond or two of router and queue delay.
| Path | Great-circle | Theoretical RTT | Practical estimate |
|---|---|---|---|
| Frankfurt → Amsterdam | 363 km | 3.6 ms | 5–7 ms |
| Frankfurt → Bucharest | 1,454 km | 14.5 ms | 20–28 ms |
| Paris → Madrid | 1,053 km | 10.5 ms | 15–20 ms |
| Amsterdam → Ashburn | 6,208 km | 62 ms | 80–95 ms |
These are estimates to plan with, not promises — measure the real thing before you commit. What the table is for is calibrating expectations: no provider, network or protocol makes Amsterdam to Virginia quicker than about 80 ms, and anyone implying otherwise is selling something.
A single round trip rarely matters. What matters is how many of them stack up before the user sees anything. A cold HTTPS request costs one RTT for the TCP handshake and one more for TLS 1.3, so the first byte of your response is already three round trips deep once the request itself is counted.
At 10 ms that is 30 ms of nothing. At 90 ms it is 270 ms, and the page has not started rendering. Add a few sequential API calls behind it and the difference between a nearby and a distant server stops being a number in a monitoring graph and becomes the reason the product feels slow.
Two corollaries worth holding onto. First, protocols that cut round trips — TLS 1.3, HTTP/2 or HTTP/3, connection reuse — buy back more on a long path than on a short one. Second, latency is not throughput: a single TCP flow across a long path is capped by its window divided by the RTT, which is why a well-provisioned server on the wrong continent can feel both fast and slow at once.
Different workloads weight the same map differently.
Interactive and real-time. Game servers, voice, trading, anything where a human reacts to a response. Distance dominates everything else; put the node in the region and accept a smaller machine if that is the trade. Our game server hosting sizes around this constraint first.
Bulk delivery. Downloads, VOD catalogues, software mirrors, backup targets. Throughput and cost per delivered terabyte matter more than the first 50 ms, so a single well-connected origin often beats three scattered ones. Interconnection density is the thing to optimise for here.
Egress-heavy streaming. A hybrid. Ingest wants a short, stable path from the encoder; egress wants to reach eyeball networks efficiently. These can point at different cities, and an origin plus regional restreamers is usually cheaper than putting full capacity everywhere.
Compliance-bound. Where the data may legally rest narrows the map before latency is even considered. That constraint wins, because it is the only one with a legal consequence attached.
Two facilities in the same metro can behave very differently, because what a location really buys you is the set of networks reachable without a long detour. A well-interconnected site hands traffic directly to the access network your user sits on; a poorly connected one sends it via transit through another country and back.
This is why the cheapest quote in a given city is not always the fastest server in that city, and why the question to ask a prospective host is not "where are you" but "who do you hand my traffic to, and where". Peering vs transit explains what each answer means in practice, and our network page lists the facilities and carriers behind ours.
Our footprint differs by product, which is worth knowing before you plan around a city we do not serve with the machine you want:
A practical pattern for a European audience: one primary in Frankfurt or Amsterdam for interconnection, a second in Bucharest or Warsaw for eastern coverage and as a failure domain, and Marseille when traffic reaches toward the Mediterranean and beyond. Add Ashburn only when you have US users, not because the map looks tidier with it.
Do not choose from a map alone. Two measurements, an hour of work:
mtr and a few timed HTTPS requests from machines in your actual markets — a cheap VPS in each region is enough — toward candidate locations. Look at the path, not only the final number: an extra 15 ms with two fewer hops usually beats a short path that crosses a congested exchange.If the top two candidates land within a few milliseconds of each other, stop optimising and pick on the other criteria — stock, price, the legal regime, and whether the location also has the storage or bandwidth tier you will want in a year.
Yes, for everything the CDN cannot cache: API calls, logins, checkout, dynamic pages and the origin fetches themselves. A CDN shortens the path for static bytes and leaves the interactive path exactly where you put it.
Usually not. One well-chosen location plus real measurements beats three guessed ones, and multi-region brings data consistency problems that cost more engineering time than the milliseconds are worth. Expand when the traffic data says where.
Not always. Routing decides the actual path, and a poorly connected nearby site can lose to a well-connected distant one. Distance sets the floor; interconnection decides how close you get to it.
Frankfurt and Amsterdam have the deepest interconnection in Europe, which is why so many origins sit there. For an audience concentrated in one country, the national metro usually wins on latency even with thinner interconnection.
You can deploy a new one there and migrate; a physical machine does not travel. Plan the cutover rather than the truck — and if you want the two boxes priced side by side while you decide, ask us.
One exit node is easy to specify and tells you nothing about the next fifty. Concurrency, throughput per session and oversubscription set subscribers per node; packet rate rather than cipher choice sets the ceiling; and country coverage wants a tiered fleet, not identical boxes.
No one can quote a player count without knowing the title, but the shape of the limit is knowable. The tick deadline binds first, memory decides instances per box, and bandwidth binds the fleet rather than the instance. Each has arithmetic you can run on your own numbers.
A streaming server does three jobs with three different bottlenecks. Ingest wants path quality, transcode wants cores, egress wants a port. Size them separately, work a real build end to end, and see why the blended ABR bitrate — not the top rung — sets the uplink.