机房城市经常被放在一起比较：香港、东京、台北、洛杉矶。这些名字本身不是快慢的原因。快慢来自用户在哪里、流量从哪上岸，以及你的数据要和谁同步。先把这三件事画出来，城市比较才有对象。
先画用户，再选城市。主要用户在华南和东南亚，香港往往是一个短路径的汇合点。用户在日本，机器放在东京比放在一个更常被称作国际枢纽的城市更直接。用户在北美西海岸，洛杉矶或附近的美西机房能减少跨洋之后还要再绕一段陆地的距离。如果用户其实集中在某一国内网，却把机器放在遥远的海外城市，再买优质线路，也只是在弥补选址，不是在优化选址。线路可以改善路径，不能取消地理距离。
从机房里 ping 出去，测不到用户的体验
时延要分方向测。从机房 ping 公共地址，只能说明机房出去的一条路径。用户到你的服务，走的是他的运营商到你的入口。晚高峰、工作日和周末可能完全不同。验收时用真实用户所在的网络去测，比在机房内互 ping 更接近体验。除了平均延迟，还要看抖动和丢包。语音、游戏和远程桌面对抖动比对平均延迟更敏感；网页和大文件下载则更在意丢包之后的重传。只报一个平均值，会把这两种问题混成一个数字。
多机房之后，时延问题会从「用户到服务器」变成「服务器到服务器」。数据库在一个城市，应用在另一个城市，每一次查询都要跨过去。这种延迟是稳定的，优化空间很小，所以权威数据应该尽量和写入请求放在近处，只把读缓存放到远处。备份可以远，事务不要远。同步复制如果跨洋，写入延迟会直接进到用户的请求里。
如果暂时只能选一个城市，就选写入最多、用户也最集中的那个方向，把其他方向先用缓存或异步任务接出去。等这个城市的晚高峰数据稳定了，再为第二组用户加节点。同时比较两个新城市时，用同一组目标、同一时段、同一批用户网络去测，否则一份白天的数据和一份晚高峰的数据会把更近的城市比输。选址决定之后，把测量样本和城市理由记在交付说明里，避免下次扩容时又从名单第一行重新开始。样本保留原始时间，不要只留一个平均值。
选址没有全球最快的城市，只有对你的用户和数据流最短的组合。把比较限制在真实的访问方向上，城市名单才会有用。测完晚高峰的延迟、抖动和丢包，再决定要不要为这个城市增加节点，比先把四个城市都买下来更接近业务。