迁移后的压测验证

业务能打开不代表迁移成功，性能掉了一半也算失败。压测验证是迁移收尾的硬关卡，用数据确认新机接得住老业务。 先定基线 压测要有参照。迁移前在老机上记录核心接口的响应时间：首页、列表页、下单接口各测一组，比如首页在 200 并发下平均响应 300 毫秒，这个数字就是基线。基线忘了留，就用业务监控里的历史曲线兜底，总比没有强。基线数据连同测试命令一起存档，下次迁移还能拿来对比。 核心链路回归 功能回归优先于性能。把登录、下单、支付、上传这几条主链路逐条走通，脚本化验证用 curl 加断言即可： curl -s -o /dev/null -w "%{http_code}" https://域名/login 返回 200 只是及格线，关键接口还要核对返回内容里的业务字段，比如订单号格式、用户昵称有没有乱码。回归要做两轮：切换当晚一轮，第二天早高峰再复测一轮，夜间正常不代表高峰正常。 压测爬坡 用 ab 这类简单工具从低并发开始，50、100、200 这样逐档加，每档观察错误率和响应时间。对新机脾气不熟，就别一上来全量打，出过把自家带宽打满、触发防御误拦的事故。ab 的常用姿势：ab -n 2000 -c 100 https://域名/，两千个请求一百并发，重点看 Requests per second 和 Failed requests 两行。 对比基线与收尾 压测结果和老机基线比：响应时间偏差在两成以内算正常，超过两成就查原因。常见的三处：新机 php-fpm 进程数偏低、数据库连接池没调大、慢查询日志里出现老机上没有的语句。数据库侧顺手开慢查询日志：set global slow_query_log=1; long_query_time=1; 压测跑完数一数超一秒的语句。 常见问题两个：压测机本身成为瓶颈，数字难看不代表服务不行，换台机器再测；防御策略把压测流量当攻击拦了，压测前先把压测机 IP 加进白名单，测完撤销。 压测不是追求好看数字，是确认迁移没有引入性能回退。有基线、有对比，迁移报告的结论才站得住。