压测和性能分析方法论

压测类型一般分为单服务压测和全链路压测两种压测类型。,而我们常见的施压模式有以下两种:,并发是指并发用户数，从业务角度来模拟同时在线的用户数，从而达到预期的并发量，要计算吞吐的话还需要做个转换。但是在某些场景比较符合场景的预期,RPS 模式（以请求的吞吐量角度来模拟吞吐模式）,并发模式与 RPS 模式没有优劣，各自有各自适用的场景。,常用压测工具如下：,响应时间和吞吐量要达到一个平衡点，随着吞吐量的增加，响应时间会先维持一个点，然后会开始迅速加大，随之而来的是吞吐量也很难上去了。我们对响应时间是有要求的，因此我们不能只追求吞吐量，一定是在一个合理的响应时间内找到最大的吞吐量。,响应时间一定是在成功率的基础上的， 如果出现失败，那么这个响应时间是无效的。成功率一般要 100%。,他们之间的关系是：,性能计数器，指的是服务器或者操作系统性能的一些指标数据，包括系统负载 System Load、对象和线程数、内存使用、CPU 使用、磁盘和网络 I/O 使用等指标。这些指标是系统监控的重要参数，反映系统负载和处理能力的一些关键指标，通常这些指标和性能是强相关的。这些指标很高，成为瓶颈，通常也预示着性能可能会出现问题。,参考 平均值是不靠谱的，最为正确的统计做法是用百分比分布统计 一文，最佳实践经验是采用百分比。比如 Top Percentile（TP）指标 ，TP50的意思是指 50%的请求都小于某个值，TP90表示90%的请求小于某个时间。,不管是哪种压测类型，压测要观察的指标一般需要包括：,一个基本的压测数据示例如下：,,我们分析系统性能问题，需要找准要点，这就要求我们的压测报告要确实有效，是要非常严谨的，条理清晰， 要一步一步分析出瓶颈，而且要明白为啥到了瓶颈，然后怎么优化？因此就要求我们要输出严谨的压测报告。这里有一些经验：,QPS 不会一直上升，到某个点后就会持平甚至下降，出现性能拐点，此时就需要开始分析原因。,具体的方式就是，先抓没有到极限的 profile 情况(cpu,block,io,内存)，再抓刚好到极限的，最后抓已经超过极限的，然后分析这几种情况下，到底是哪个系统资源，或者外部接口导致了性能问题。,如果是某个组件或者外部服务是性能瓶颈点，那么还需要进一步分析下，是不是组件的使用姿势不对？是不是没处理好连接数？不能说一找到某个组件的问题就结束了，还需要进一步更深层的审视下。,单台机器的最大 QPS 是多少？,平行扩展后的 QPS 又是多少，是线性增长么?（肯定不会线性增长, 到某个程度后相关资源一定都会出现瓶颈，关键是要找到对应的瓶颈点）,首先看 CPU，如果 CPU 没有跑满，则说明不是 CPU 的问题，就不用关心CPU，然后就要其他的资源如 io, swap, 内存, 网卡等,如果有多个 CPU 核心, 则观察每个核心的 cpu 的使用情况，不能光看整体的 CPU 使用率,如果 CPU 跑满了，那么抓 CPU 的 profile, 观测看看哪个调用比较耗时.,系统上线前就必须要能够有预估/评估大概, 再通过压测验证, 了解每个细节,包括资源, 依赖关系, 部署情况, 机房分布, 降级策略, 容灾方案, 备用方案,容量预估是大型系统上线的必备品，因为只有合理的进行容量预估，才能更好的去根据系统要承载的量级去设计我们的系统，容量规划需要尽量做到以最少的机器抗住更多的流量；规划 ok 了之后，我们需要用一些性能压测手段来验证是否符合预期。有了合理的容量规划和评估之后，上线之前去压测系统的时候才能知道我们需要压到什么程度，然后，容量预估并不是拍脑袋的，容量评估需要考虑如下几点：,要做好分析总结，比如：,高质量的测试数据应当能真实的反映用户的使用场景，我们一般会选择以线上真实数据作为数据源，经过采样、过滤、脱敏，作为性能测试的测试数据。但是在拿真实数据测试之前，必须要先线下模拟测试数据，至少先验证整个系统的基本性能需求后才能拿真实数据做性能测试。,针对无状态服务的话，要提高并发能力很容易，可以无脑扩容。但是针对有状态的存储系统，它能支持的最大并发数不是可以无限扩展的，因此我们一定要能够清楚我们的数据存储层能抗多少量，而针对这种存储集群的压测，一般就是：,文转载自微信公众号「 后端系统和架构」，作者「 AllenWu」，可以通过以下二维码关注。,,转载本文请联系「后端系统和架构」公众号。