做完一次网站诊断，才发现问题不在服务器

网站一慢，第一反应就是机器不够用，这个反射弧太短了。做完一次网站诊断才发现问题不在服务器，这话我跟不少人说过，对方往往先愣一下——监控面板上CPU和内存都平得像把尺子，怎么会不是服务器？可用户那边点开页面，一层一层往下掉，白屏时间长得能去泡杯茶。这时候再谈升级配置，钱是花了，页面还是那个鬼样子。

诊断的活儿，第一步是分账。后端一摊、前端一摊、网络一摊，三摊搅在一块儿看，永远看不出门道，最后只能凭感觉拍板，拍错了还得推倒重来。

做完网站诊断才发现问题不在服务器，前后端得分开记账

后端看的是响应时间，请求打到服务器，程序跑完吐出第一个字节花了多久；前端看的是浏览器拿到东西之后，还要下多少图片、执行多少脚本、重排多少次版面。这两件事儿的负责人压根不是同一个人，你拿服务器的指标去解释前端的卡顿，解释不通。我一般会让对方把浏览器开发者工具里的网络面板截个图发过来，一行一行扫，哪条请求又大又慢，基本就露馅了。这方法很土，但比盯着十张监控图看管用。

先看时间线，别一上来就盯CPU

有的站是全天都慢，有的是晚上某个点开始慢，有的是刚发完内容慢上一阵子。这三种情况指向的东西完全不一样。全天慢，通常说明页面本身太重，或者数据库缺索引；按点慢，多半撞上了备份任务、定时脚本、日志切割这些跑在后台的活儿；发完内容才慢，可能是缓存被清了个干净，全站又在回源重建。

连什么时候慢都没弄明白就去换机器，运气好蒙对了，运气不好就是白折腾一趟。让人把一周里几个明显的慢时段记下来，这动作花不了十分钟，价值比跑分高。

图片和第三方脚本，吃掉的是首屏

首页首屏塞几十张图的站我见太多了，全是原图直传，一张好几兆，谁也不管。这种站跟服务器一点关系没有，你给它堆到八核十六G，用户照样得等图片一张张爬下来。压一下、转个格式、首屏之外的先别加载，体感立马不一样。

第三方脚本更隐蔽。统计代码、客服浮窗、广告位、图标字体，单看每个都不大，加起来可能比你自己写的业务代码还重。这些东西还大多托管在别人家的域名上，对方抽个风，你的页面就跟着卡。诊断的时候把外部域名的请求单独拎出来数一数，数量超出预期是常事。

缓存这块，配置好坏差别很大

同一台机器，缓存配得好和配得马虎，体感能拉出一大截。静态资源给长缓存、页面走CDN、动态接口按情况给短缓存，这些动作不花什么钱，见效还快。反过来，缓存规则写拧了也会出怪事——内容明明更新了，用户还在看旧页面，这类投诉得另开一摊去查，别跟慢混在一起。

数据库慢查询和程序里的死循环，也常被算到服务器头上

有没有索引，一条查询的耗时能差出好几个数量级，这个不用多说。更麻烦的是有些程序跑着跑着就往库里灌重复数据，日积月累，一个列表页要扫几十万行。这时候CPU确实被忙起来了，可原因不在机器弱。打开慢查询日志，挑反复出现、扫描行数离谱的那几条改，往往比换机器便宜得多。顺手也看看有没有定时任务重叠着跑，撞在一起的效果跟被人打了差不多。

换机器之前，按这个顺序过一遍

我的习惯是这样：先确认响应时间和首屏时间是不是同一回事；再看图片有没有压过、有没有按需加载；然后数第三方请求；接着翻缓存头和CDN回源配置；最后才去看数据库慢查询和负载曲线。一套走下来，问题卡在哪一层基本能定性。

还有个细节，监控别只看平均值。平均好看，尖峰很难看，而用户体验恰恰由尖峰决定。看高分位耗时、看最大耗时，比看平均有用得多。这条我在很多面板上都提过，能听进去的人不多。

诊断完了，优先级比结论更重要

一次诊断最有价值的地方不是那份报告，而是它排出来的先后顺序。先做不花钱的，再做花钱少的，最后才考虑升配置。顺序反了，你会在错的方向上越走越远，还觉得是钱没花够。

顺带说一句，做完网站诊断才发现问题不在服务器，这话不是让你永远别升级硬件。流量真涨上来、程序真把资源吃满了，该加还得加。只是别把它当成处理慢的第一反应。

下次页面打开慢，先花半小时把网络面板和服务器日志对着看一遍，把两边的数字摆在一起。多数时候答案就在那儿，跟换不换机器关系不大。