容量评估冒险：挑战极限，究竟要压到何种程度才能“摸到”最大容量？

背景

觉得系统有性能瓶颈，但不知道在哪！！！ 怎么找？压测。

搭建一套与pro环境相同配置的服务成本比较高，大多数公司会选择直接在线上压。 因为全链路的混合流量更接近实际的业务场景，同时，风险也高。 那么，既要不影响系统使用，也要找出性能瓶颈，需要

在什么时候喊“停”？

出现明显的性能拐点时，就找到了系统的性能瓶颈，摸到最大容量。

性能拐点的表现： 增大压力后，接口的QPS没有同比上升，但响应时间显著增大，譬如增大1倍+。

同时伴随着其它指标开始出现异常，包含但不限于：

• 服务所在主机的CPU利用率接近或达到警戒阈值，譬如100%

• 服务所在主机的内存利用率接近或达到警戒阈值，譬如100%
• 服务的Young GC更加频繁，譬如GC次数达到时间的2倍
• 服务出现Full GC，且频繁出现

• 服务的线程数增加，同时WAITING状态的线程同时增加

• 数据库的资源利用率接近或达到警戒阈值，譬如90%
• Redis的资源利用率接近或达到警戒阈值

找到性能瓶颈后，下一步干什么？

在出现性能拐点时，保存现场快照。

对于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