如何从电商网站性能测试结果定位制约应用扩容的瓶颈问题

1. 问题场景的链路Trace维度拆解 #

• 先提取结算、登录后场景的全链路调用日志，统计每个下游依赖的耗时占比：重点看数据库查询、缓存调用、第三方接口（比如支付、用户中心）的响应时长，排查是不是应用服务器在等下游返回导致整体耗时高，扩容应用服务器根本解决不了下游的瓶颈
• 统计这两个场景的报错类型：如果是504网关超时、429请求限流类报错，优先查上游网关/负载均衡的限流阈值是不是设太低，扩容的应用实例根本没接收到请求；如果是502错误要排查实例健康检查配置是不是异常，扩容出来的实例没被接入流量池

2. 未覆盖的基础设施层指标排查 #

• 应用服务器的内存指标：不要只看CPU和I/O，重点盯堆内存使用率、GC频率/耗时，如果是JVM类应用，GC停顿时间过长会导致所有请求都卡，哪怕CPU使用率不高，扩容也解决不了内存层面的全局停顿问题
• 网络层指标：测单实例的网络带宽占用、TCP连接数、TIME_WAIT状态占比，还有同可用区的网络延迟，如果是网络带宽打满或者TCP连接耗尽，扩容后整体网络瓶颈依然存在，响应时间不会下降
• 数据库/缓存层指标：拉取对应压测时间段的数据库慢查询日志、缓存命中率、连接池使用率，很多电商的结算场景会锁库存、查大量用户订单，数据库连接池打满或者行锁冲突的话，哪怕应用扩容10倍，请求都卡在等数据库连接，耗时不会有改善

3. 应用架构层面的配置校验 #

• 查应用的连接池配置：比如数据库连接池、HTTP客户端连接池的最大连接数是不是设的过低，单实例的连接数满了之后，哪怕服务器CPU再闲，新请求也得排队等连接，扩容只能线性加总连接数，但如果数据库侧的最大连接数设了上限，扩容到超过数据库连接阈值之后反而会报错
• 查分布式锁的实现：结算、登录场景大概率会用到分布式锁，要是锁的粒度太粗、锁等待时间太长，或者锁的底层实现（比如Redis）本身出现性能瓶颈，扩容应用只会增加更多抢锁的请求，反而会让整体耗时更高
• 查流量分发规则：负载均衡是不是用了会话保持，登录后用户的请求全粘到少数几个实例上，扩容出来的新实例根本没分到流量，自然不会改善整体响应时间

内容的提问来源于stack exchange，提问作者Rickshaw Tomtom