调了一周，测速几乎没动

接手一台慢机器，我先按经验调了一轮：改内核参数、加缓存、调 worker 数量，自我感觉做得挺足。上线后用多节点测了一遍，和优化前几乎没区别。

问题在于我一直待在机器里看数字，从来没站在用户的位置看时间花在哪。

先量，再改

优化前第一件事是留基线。宝塔拨测的网站测速跑多地区多运营商节点，记录五段耗时、状态码、平均、最快、最慢。

之后所有改动都拿同一批节点对比。换节点、换时段，测出来的差异可能比优化本身还大。

基线至少要包含两样东西：正常状态下的五段耗时，以及最慢节点卡在哪一段。少了这两样，后面所有「优化」都没有对照物。

网站测速：多站点分段耗时与状态码

网站测速：多站点分段耗时与状态码

五段耗时决定改哪里

DNS 段长，动的是解析服务、TTL、记录配置，跟 ECS 的配置没关系。

TCP 段长，看线路、丢包、安全组。跨运营商差异大，说明该考虑多线或者 CDN，而不是加 CPU。

TLS 段长，看协议版本、证书链、会话复用。这部分优化空间明确，收益也稳定。

TTFB 长，这才是机器侧该动的地方：程序、数据库、缓存命中率。

下载段慢，先看资源体积和带宽，再谈服务器。

机器上真正有用的几处

连接保持，减少重复握手；worker 数量跟并发匹配，不是越大越好；PHP 类应用开 opcache；数据库看慢查询和索引；静态资源开压缩、配好缓存头。

这些改动的共同点是能直接改善某一段耗时。改完必须回到同一段去验证，否则你判断不了是它起了作用，还是别的因素。

还有个常被忽略的点：日志写入方式。同步写日志在高并发时会把 TTFB 拖起来，改成异步或者降低日志级别，往往比调参数见效更快。

带宽和 CDN 常被低估

很多「服务器慢」其实是带宽不够，或者跨网质量差。加 CPU 不会让下载变快，把静态资源交给 CDN 才会。

按运营商分组看最慢节点。如果慢的总是那几家，优化机器就是绕远路，先解决线路，再谈参数。

判断带宽是否吃紧，看下载段在各地是不是同时变慢。全部变慢偏出口带宽，只有部分地区变慢则更像线路问题。

复测才算完成

改完连测三次，看同一段耗时是不是真的下降、最慢节点有没有收敛。只看平均值，很容易掩盖局部恶化。

该警惕的是：优化后总时长没变但某一段暴涨（问题只是被挪了位置）、只有本地变快、状态码开始出现 5xx。出现这些，先回滚，再重新量一遍。