面向北美用户的服务，机器放在哪里，比口号里的全球加速更决定体验。美国服务器，尤其是洛杉矶服务器，适合用户在美西，或业务需要一条比较短的跨太平洋落地。用户的请求从北美本地网进来，页面、接口和文件下载都少一次跨洋之后再在陆地上绕行。如果用户其实在东亚，却把整站放在洛杉矶，再购买国际带宽，只是在为错误的选址付费。
洛杉矶机房常被用来承接从亚太过来的跨洋流量，也用来服务美国本土。这两类用户不要混在同一段验收里。本土用户看的是洛杉矶到美国运营商的路径是否稳定。亚太用户看的是跨洋之后落地是否还要再绕。云服务器适合官网、账户系统和可以水平扩展的接口。独立服务器适合数据库、队列和对磁盘吞吐更敏感的后台。服务器租用时，把写入集中在洛杉矶这一侧，只把读缓存放到远处。数据库留在香港、应用放在美国，每一次查询都要跨洋。页面会快，登录和保存会慢。
国际带宽按用户所在的晚上来看
国际带宽在这里是容量。面向美国用户的下载、备份和日志回传，按峰值并发估算端口，并确认是独享带宽还是共享。共享端口在美国晚高峰，也就是亚太的白天，可能仍然拥挤。测速如果只在亚洲工作时间做，会把一条实际上会堵的线路测成空闲。带宽图要留到用户所在时区的晚间再看。独享带宽贵在晚高峰仍然按购买速率转发，不在于白天的测速更好看。
和香港服务器、日本服务器相比，洛杉矶的优势是离北美用户近，而不是配置更高。同样的云服务器规格，放在错误的城市，处理器再多也填不平距离。如果业务同时有北美客户和大陆客户，入口应拆开：北美走美国服务器，大陆走香港方向的优化线路，证书、解析和健康检查按入口分别配置。用一台洛杉矶机器的国际带宽去应付大陆用户的晚高峰，页面能打开，交互会明显变沉。日本服务器同样不该被当成北美业务的中转，除非用户确实在日本。
美东慢，不一定是洛杉矶的端口不够
验收时从美西、美东各选一家常见运营商，在当地晚高峰访问首页、登录和一次文件下载。美东用户到洛杉矶本身就有一段横贯大陆的延迟，这是地理，不是故障。如果美西已经稳定、美东波动很大，先确认是不是还需要美东节点，而不是立刻把洛杉矶的带宽加大。加大带宽改善的是并发容量，不改善横贯大陆的传播时间。物理服务器或裸金属服务器可以提高磁盘和网络的隔离，也不能把美东搬到美西。
写入路径要单独列出来。注册、下单、保存设置和支付结果都应该落在洛杉矶的独立服务器上，由同机房的云服务器提供页面和只读接口。只读接口可以缓存，写入不要为了多一个机房而跨洋同步复制。跨洋同步复制会把传播时间加进每一次保存。备份可以放得远，事务不要放得远。这和选哪一家美国服务器品牌无关，和数据跟请求是否放在一起有关。
下载和更新包是另一类流量。安装包、镜像和备份如果直接从业务机器吐出，会把页面和接口的带宽一起打满。把大文件放到单独的下载地址，用国际带宽或对象存储承接，业务端口只留交互。服务器租用合同里如果只写了一条美国 100M，上线后第一个周末的更新就会证明这条端口同时服务了不该混在一起的两类流量。
如果后来增加大陆或日本用户，不要把洛杉矶这台机器的国际带宽直接加大来兼顾。大陆用户另走香港服务器上的优化回国线路，日本用户另走日本服务器，洛杉矶只保留北美的写入和页面。三边的证书和健康检查分开，某一边晚高峰拥塞时，另外两边的登录和保存仍落在各自的数据库旁边。服务器租用的月费会多出几台，但每一台的带宽都有明确的用户，不会在一份跨洋账单里互相拖慢。
采购说明里建议写清四件事：哪些接口必须和数据库在同一城市，哪些可以缓存，国际带宽是独享还是共享，以及样本采集的时区。美国服务器不是一个笼统的更快选项。它只在用户和写入都靠近美西时，才是短路径。用户地图没有画出来之前，洛杉矶、香港和东京都只是名单上的城市。先画用户，再比较服务器租用的价格。