目录上线前压测主要排查什么问题1. 性能指标是否达标功能没问题≠性能没问题2. 资源瓶颈定位CPU、内存、IO、网络、连接数3. 并发下业务逻辑 Bug单测、接口测试测不出来4. 中间件与依赖服务稳定性5. 高并发下的稳定性、雪崩效应6. JVM 相关隐患哪些场景可以不用完整压测压测环境注意点很关键很多人踩坑上线前压测输出物补充上线之后也需要做结论生产上线前压测非常有必要尤其是微服务、高并发接口、支付 / 订单 / 充电计价这类核心链路小流量内部管理后台可以简化但核心业务接口建议至少做基准压测。区分两个概念基准压测必做验证系统在预期 QPS 下能不能稳跑找到基线性能指标。极限压测可选把系统打崩看崩溃点、雪崩现象一般预发布环境做不强制。上线前压测主要排查什么问题1. 性能指标是否达标功能没问题≠性能没问题接口平均响应时间、P95、P99 响应时间很多接口正常单调用很快并发上来 P99 直接超时。支持的安全 QPS知道系统能扛住多少流量为后续限流、扩容、云服务器规格选型提供依据。吞吐量 TPS业务处理能力是否满足预估业务峰值。像智慧充电设备上报、订单创建、计价结算峰值流量上来如果 P99 很高会出现大量设备上报超时、订单异常。2. 资源瓶颈定位CPU、内存、IO、网络、连接数压测时观测服务器指标提前发现资源短板CPU线程死循环、复杂 SQL、频繁 GC、序列化反序列化消耗过高。内存内存泄漏、OOM 隐患并发下对象疯狂创建老年代快速占满FullGC 频繁。IOMySQL 慢 SQL、索引缺失磁盘 IO 打满ES 查询过慢磁盘压力大。连接池耗尽数据库连接池、Redis 连接池、Tomcat 线程池、Netty 连接耗尽大量请求排队报错。典型坑开发环境单请求一切正常并发上来直接报could not get connection。3. 并发下业务逻辑 Bug单测、接口测试测不出来很多问题只有多线程并发才暴露并发更新导致超卖、重复订单、数据错乱乐观锁 / 悲观锁没生效未做幂等重复请求产生多条脏数据分布式锁失效多线程同时修改同一条业务数据定时任务并发重复执行XXL‑Job 虽然有控制但业务代码依然可能出问题4. 中间件与依赖服务稳定性压测会真实考验整个调用链MQ生产消费速度是否匹配消息堆积、消费阻塞、重复消费。Redis大 key、热 key并发击穿缓存缓存雪崩。MySQL慢查询暴露锁等待、行锁冲突事务过长。第三方依赖调用外部 HTTP 接口超时没有合理降级、熔断拖垮整个服务。5. 高并发下的稳定性、雪崩效应没有限流熔断下游服务抖动导致本服务线程池被占满服务雪崩。超时时间设置不合理接口超时时间太长请求不断堆积。长连接场景WebSocket大量设备同时接入连接管理、消息推送错位。6. JVM 相关隐患并发下 GC 情况是否频繁 FullGC、STW 停顿时间过长。大对象分配内存占用暴涨上线后高峰期直接 OOM。哪些场景可以不用完整压测内部管理后台用户极少并发很低只做简单基准测试即可。纯离线后台任务无在线流量。但对外 C 端、设备端、订单支付、计费类强烈建议压测。压测环境注意点很关键很多人踩坑不要直接压生产环境使用预发布 / 性能测试环境环境配置尽量贴近生产。数据量尽量模拟生产量级空库压测没有参考价值MySQL 没有真实数据索引、锁不会暴露问题。压测同时必须观测指标CPU、内存、磁盘 IO、网络、GC 日志、数据库慢日志、SkyWalking 链路。上线前压测输出物各核心接口安全 QPS、P95/P99 耗时。系统瓶颈点记录哪个接口、哪个 SQL、哪个中间件是短板。限流阈值建议、机器扩容建议。已知风险点上线重点观测清单。补充上线之后也需要做压测只是上线前体检上线后还要做线上真实流量回放、观测监控告警真实业务流量才是最真实的压测。
上线前压测有没有必要做？排查哪些问题
目录上线前压测主要排查什么问题1. 性能指标是否达标功能没问题≠性能没问题2. 资源瓶颈定位CPU、内存、IO、网络、连接数3. 并发下业务逻辑 Bug单测、接口测试测不出来4. 中间件与依赖服务稳定性5. 高并发下的稳定性、雪崩效应6. JVM 相关隐患哪些场景可以不用完整压测压测环境注意点很关键很多人踩坑上线前压测输出物补充上线之后也需要做结论生产上线前压测非常有必要尤其是微服务、高并发接口、支付 / 订单 / 充电计价这类核心链路小流量内部管理后台可以简化但核心业务接口建议至少做基准压测。区分两个概念基准压测必做验证系统在预期 QPS 下能不能稳跑找到基线性能指标。极限压测可选把系统打崩看崩溃点、雪崩现象一般预发布环境做不强制。上线前压测主要排查什么问题1. 性能指标是否达标功能没问题≠性能没问题接口平均响应时间、P95、P99 响应时间很多接口正常单调用很快并发上来 P99 直接超时。支持的安全 QPS知道系统能扛住多少流量为后续限流、扩容、云服务器规格选型提供依据。吞吐量 TPS业务处理能力是否满足预估业务峰值。像智慧充电设备上报、订单创建、计价结算峰值流量上来如果 P99 很高会出现大量设备上报超时、订单异常。2. 资源瓶颈定位CPU、内存、IO、网络、连接数压测时观测服务器指标提前发现资源短板CPU线程死循环、复杂 SQL、频繁 GC、序列化反序列化消耗过高。内存内存泄漏、OOM 隐患并发下对象疯狂创建老年代快速占满FullGC 频繁。IOMySQL 慢 SQL、索引缺失磁盘 IO 打满ES 查询过慢磁盘压力大。连接池耗尽数据库连接池、Redis 连接池、Tomcat 线程池、Netty 连接耗尽大量请求排队报错。典型坑开发环境单请求一切正常并发上来直接报could not get connection。3. 并发下业务逻辑 Bug单测、接口测试测不出来很多问题只有多线程并发才暴露并发更新导致超卖、重复订单、数据错乱乐观锁 / 悲观锁没生效未做幂等重复请求产生多条脏数据分布式锁失效多线程同时修改同一条业务数据定时任务并发重复执行XXL‑Job 虽然有控制但业务代码依然可能出问题4. 中间件与依赖服务稳定性压测会真实考验整个调用链MQ生产消费速度是否匹配消息堆积、消费阻塞、重复消费。Redis大 key、热 key并发击穿缓存缓存雪崩。MySQL慢查询暴露锁等待、行锁冲突事务过长。第三方依赖调用外部 HTTP 接口超时没有合理降级、熔断拖垮整个服务。5. 高并发下的稳定性、雪崩效应没有限流熔断下游服务抖动导致本服务线程池被占满服务雪崩。超时时间设置不合理接口超时时间太长请求不断堆积。长连接场景WebSocket大量设备同时接入连接管理、消息推送错位。6. JVM 相关隐患并发下 GC 情况是否频繁 FullGC、STW 停顿时间过长。大对象分配内存占用暴涨上线后高峰期直接 OOM。哪些场景可以不用完整压测内部管理后台用户极少并发很低只做简单基准测试即可。纯离线后台任务无在线流量。但对外 C 端、设备端、订单支付、计费类强烈建议压测。压测环境注意点很关键很多人踩坑不要直接压生产环境使用预发布 / 性能测试环境环境配置尽量贴近生产。数据量尽量模拟生产量级空库压测没有参考价值MySQL 没有真实数据索引、锁不会暴露问题。压测同时必须观测指标CPU、内存、磁盘 IO、网络、GC 日志、数据库慢日志、SkyWalking 链路。上线前压测输出物各核心接口安全 QPS、P95/P99 耗时。系统瓶颈点记录哪个接口、哪个 SQL、哪个中间件是短板。限流阈值建议、机器扩容建议。已知风险点上线重点观测清单。补充上线之后也需要做压测只是上线前体检上线后还要做线上真实流量回放、观测监控告警真实业务流量才是最真实的压测。
