运营中心服务器响应提速40%，用户操作零等待

　　跟产品吵。去年八月份，运营中心那个接口，我原以为把 redis pipeline 拉满、把 PHP-FPM 的 pm.max_children 调到 128 就够了，结果凌晨三点跑压测，前端甩过来的 Lighthouse 跑分截图发到群里——没人回。PM 当时在吃盒饭，盒饭盖子都没掀开，就问“能不能加个 loading 动画”，我说你先去把那个 nginx upstream keepalive_timeout 从 60 改成 72，他说“这个和 loading 有关系？”，我没理他，转头看见桌面那个没关的录屏，正对着 Chrome DevTools 的 Network 面板，左上角时间戳是下午三点零七分，录着一半，没声儿，但能听见空调外机嗡嗡响。

　　首屏救火？不，这次是后台列表页。就是运营每天刷八百遍的那个“投放计划管理”表头下面的数据——原来点“导出 Excel”要等三秒半，中间用户手都松开了，鼠标移走了，结果弹窗才蹦出来，还遮住刚点的“暂停计划”按钮。现在？点了就出，快得像没点。不是加了个 defer，不是拆了 chunk，是真把那个写死在 foreach 里嵌套查 MySQL 的旧逻辑，连砍三刀：第一刀删掉“每次导出前校验所有关联渠道配额”的冗余 CHECK；第二刀把“生成唯一导出任务 ID”从 UUIDv4 换成微秒级自增+盐值哈希；第三刀最绝——把整个导出流程从同步改异步，但异步通知不走 Webhook 不走 RabbitMQ，就塞进同一个 Redis list，用 crontab 每两秒扫一次——就这么土。PM 还想加个“导出进度条”，我当场说：“你进度条读的是 Redis llen，它比你的鼠标悬停事件还快，你放那儿只会让用户误以为卡了。”

　　优胜劣汰？对。不是技术淘汰人，是请求淘汰请求。原来那个 /api/v2/ops/export_plan 接口，高峰时排队 137 个未响应，nginx log 里全是 upstream timed out (110: Connection timed out)，现在队列常年是个位数，偶尔归零。但你知道最讽刺什么吗——上周五我看见前端在 debug 一个“点击后按钮没变灰”的问题，查了半天发现是他们用了个带防抖的 Vue 指令，debounce 值设成了 300ms，而我们现在平均响应才 18 毫秒，用户点下去，按钮还没来得及 addClass('is-loading')，Excel 已经开始下载了。他删掉 debounce 的时候手抖，删了三遍才删干净。这个我敢打包票。

　　不过那个 CDN 账单……哎，扯远了。上个月突然多出十八万，运维说“你们新上了资源预加载”，我说我们压根没配 preload link，只加了 header Cache-Control: public, max-age=31536000 ——结果发现是 CDN 厂商偷偷把 /static/js/ 这个路径自动开了 Brotli 压缩兜底策略，又把 /api/ 下某些 OPTIONS 请求也缓存了三十秒，导致跨域预检返回 200 而不是 204。我让后端同事去提工单，他换了一根 Type-C 充电线——白色的那根，原装，插上去电脑右下角提示音是“咚”，不是“咚咚”。这事儿现在还没闭环。

文章配图，仅供参考

　　还有件小事：之前合并代码，老王总爱在 PR 描述里写“修复一处偶发超时”，然后贴一段 curl -X POST 的截图，连 -H 都不带全。上周他提了个合并请求，标题叫“优化导出耗时”，内容空着，只附了两个文件改动——一个是 config/autoload/cache.php 加了 'export_ttl' => 300，另一个是 application/Logic/ExportLogic.php 里删了整整四十七行 for 循环里套 DB::table()->where()->first() 的代码。我勾选“Approve”，点“Comment”，输入“可以”，删掉，重输“行”，又删，最后直接点了 “Merge pull request”。过程拆开算：第一次点 Merge 按钮（光标悬停）→ 移动到 Confirm 弹窗确认框 → 按回车。总共花了十一秒。中间他去倒水，接了两杯，一杯给自己，一杯放我桌上——水渍在键盘右侧凝了片淡痕，到现在还没干。

　　零等待？别信这个词。它骗自己。用户没等，是因为他根本感知不到“等”这个动作了——就像你眨眼睛时看不见黑，不是没黑，是黑得不够长。我们现在那个“暂停计划”按钮，点了之后前端会立即 disable，但实际后端响应只有十八毫秒，于是用户手指一抬，按钮还灰着，可接口早执行完了。这就造成一种幻觉：系统太顺了。可昨天 QA 提了个 Bug：“暂停后刷新页面，状态还是‘运行中’”，我看了一眼，是前端没轮询也没监听 SSE，纯粹靠 location.reload()——而 reload 后的 GET 请求，恰好撞上了 PHP opcache 缓存失效后的首次重编译，那 312ms 的毛刺，比以前整条链路还长。这个我说不准，可能得看今晚 opcache.revalidate_freq 设多少。

　　所以啊，提速这事吧……它不会停下。你刚砍掉一个 foreach，产品经理明天就会加三个“按组合条件筛选导出”。我下周打算把导出结果的 ZIP 打包从 exec('zip') 换成 PHP 7.4+ 的 ZipArchive::addGlob，但我不确定要不要同时把 memory_limit 从 512M 开到 1G——毕竟上次调高，第二天监控就报警 OOM，查出来是某同学在全局异常捕获里写了 var_dump($e->getTraceAsString())，Trace 深度七层，其中三层在 vendor/monolog/monolog/src/Monolog/Handler/StreamHandler.php。算了，先不动。先看看这周导出失败率有没有跌破千分之零点三。要是没破，我就去申请买那台二手 Dell R730——反正闲着也是闲着。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!