背景
觉得系统有性能瓶颈,但不知道在哪!!! 怎么找?压测。
搭建一套与pro环境相同配置的服务成本比较高,大多数公司会选择直接在线上压。 因为全链路的混合流量更接近实际的业务场景,同时,风险也高。 那么,既要不影响系统使用,也要找出性能瓶颈,需要
在什么时候喊“停”?
出现明显的性能拐点时,就找到了系统的性能瓶颈,摸到最大容量。
性能拐点的表现: 增大压力后,接口的QPS没有同比上升,但响应时间显著增大,譬如增大1倍+。
同时伴随着其它指标开始出现异常,包含但不限于:
找到性能瓶颈后,下一步干什么?
在出现性能拐点时,保存现场快照。
对于Java应用来,获取JVM的Heap dump和Thread dump数据; 对于数据库瓶颈,梳理不规范的SQL、耗资源的SQL; 对Redis的瓶颈,梳理调用链路,确定出现慢的原因;
小结
事前:确定目标。找到系统性能瓶颈,验证担心 事中:线上压测的节奏把握。保留必要的现场 事后:分析数据,确定根因,fix。准备下一次复测
补充
DEV【Development environment】开发环境,用于开发者调试使用。 FAT【Feature Acceptance Test environment】功能验收测试环境,相当于alpha环境。 UAT【User Acceptance Test environment】用户验收测试环境,相当于beta环境(回归测试、集成测试) PRO【Production environment】生产环境 https://www.apolloconfig.com/#/zh/deployment/distributed-deployment-guide