微服务性能测试

服务端压测简介

2020-07-12  本文已影响0人  lvyz0207

单系统压测与全链路压测

为什么只做单系统压测还不够呢？

在活动开始的瞬间，各系统都面临自身服务的巨大的压力，而系统之间是有互相依赖关系的，单机压测没有考虑到依赖环节压力都比较大的情况。一个系统出现故障，故障会在链路流转过程中层层累加，会造成无法评估的影响。

所以最可靠的方式是完全模拟真实场景来压测，通过线上全链路压测提前发现问题。

压测流程

完整的压测流程一般包含下面几个步骤，引用自文末参考资料：

  1. 压测目标的制定

  2. 压测链路的梳理

  3. 压测环境的准备

  4. 压测数据的构造

  5. 发压测试

  6. 瓶颈定位及容量微调

  7. 压测总结

image

压测目标

压测作用

压测指标

列举一些常用指标，并不一定都需要关注，根据业务考虑指标的细化粒度。

这里要说明一下QPS和TPS的区别：

性能测试中，平均值的作用是十分有限的，平均值代表前后各有50%的量，对于一个敏感的性能指标，我们取平均值到底意味着什么？是让50%的用户对响应时间happy，但是50%的用户感知到响应延迟？还是说50%的时间系统能保证稳定，而50%的时间系统则是一个不可控状态？

平均响应时间这种指标，只有在你每次请求的响应时间都是几乎一样的前提下才会有一样。再来个例子，人均财富这个概念有多沙雕相信大家也明白，19年有个很搞笑的新闻——腾讯员工平均月薪七万，明白平均值多不靠谱了吧😂。下图是现实世界中一个系统的响应时间柱状图，RT在前20%的请求数较少，但是因为耗时特别短（拉高了均值可能是命中缓存，也可能是请求的快速失败），而大多数RT是在均值之下，那才是系统的实际性能情况。

image

所以说，我们不应看最好的结果，相反地，应该控制最坏的结果，用户用得爽他不保证会传播好口碑，但是用户用到生气他保证变为键盘侠肆意大骂，这也是为什么平均值无法带来足够的参考，因为happy的结果蒙蔽了我们的双眼，平均值在压测中丢失太多信息量。

总结一下，较为科学的评估方法应该将指标-成功率-流量三者挂钩在一起的：

xx%的响应在xx毫秒内返回，其中成功率为xx%。

根据这个方针，可以得到一些测试思路：

  1. 在响应时间的限制下，系统最高的吞吐量（这里不对吞吐量做严格定义，当成是QPS或TPS即可）

  2. 在成功率100%的前提下，不考虑响应时间长短，系统能承受的吞吐量

  3. 容忍一定的失败率和慢响应，系统最高能承受的吞吐量（95%成功率，前95%的请求响应时间为xx毫秒时的最大QPS）

  4. 在上面的场景下还要考虑时间和资源，比如最高吞吐量持续10分钟和持续1小时是不一样的，不同的时间持续长度下，机器资源（cpu、内存、负载、句柄、线程数、IO、带宽）的占用是否合理

目标预估

压测开展前是需要有目标的，也就是有期望的性能情况，希望接口或系统能达到的性能预期，没有目的的压测是浪费人力，下面给出几种目标预估的方法。

历史监控数据

已经上线并且有历史监控数据的接口，可以查看历史数据，找出峰值QPS和PCT99。🌰 若接口A已经上线并且做了监控，在经过某次大活动或者上线时间足够长后，存量监控数据就可以使用了。

类比

新接口或者线上未监控的接口，不存在历史数据，但存在类似功能接口的历史监控数据，可以通过类比得出压测的目标。🌰 假设上一年淘宝双十一下订单接口QPS=x，RT=y，这一年天猫平台整起来了，双十一活动与上年淘宝双十一活动场景类似，也沿用QPS=x，RT=y的目标（例子不严谨，理解即可）。

估算

新接口或者线上未监控的接口，不存在历史数据，且不存在类似功能接口的数据可供参数考，此时需要估算峰值，常用方法有8/2原则——一天内80%的请求会在20%的时间内到达。

top QPS = (总PV * 0.8) / (60 * 60 * 24 * 0.2)

RT如无特殊要求，一般采用默认值：

🌰-1 电商秒杀活动，预估同时有1000w人参与，简单起见假设总QPS是1000w。由于前端不同的秒杀倒计时形式使得请求有2s的打散，再加上nginx等webserver做了20%几率拒绝请求的策略，所以下单接口总QPS = 1000w / 2 * (1 - 0.2) = 400w/s，最终压测目标为400w/s的QPS。

🌰-2 电商全天低价抢购活动，屠龙宝刀，点击就送，一刀99级，emmmmm跑题了。根据8/2原则，预估在午休（12-1）和晚上下班后（7-10）共4h是流量高峰，估算接口峰值QPS = 活动全天接口PV / (4*3600s)。

其他

除了前面说到的情况，肯定还有一些我们无法下手的三无接口，无参考、无预估、无历史数据，这时候只能一点一点来，慢慢把压力提上去的同时收集数据，最终得出接口的最优处理能力。

image

压测准备

压测场景

压测是有目的的压测，也就是说不是随便找些接口发一通压力，而压测全部的接口也是做不到的或者说无意义的，得有压测的优先级，所以梳理压测场景是很重要的。高优场景主要有下面几个：

  1. 高频业务场景（今日头条首页下拉刷新）

  2. 关键业务场景，使用频率低，一旦出问题就很严重（微信账号登录）

  3. 性能高消耗场景（淘宝下单）

  4. 曾经出现过问题的场景

压测有分单接口压测和场景化压测，前者会简单一些，后者一般是多个接口混合操作以组成一个业务场景，两者在方法上是相通的。

梳理场景时QA需要与RD对齐，确认不同接口的RD负责人、需要压测的接口、系统性能现状以及压测目标；在确定每个接口的压测目标时，要考虑到压测对象是单实例单机房还是集群；在细节上也要确认是单接口压测还是场景化压测，每个接口的流量占比以及优先级，需不需要发足够的压力来触发系统的自动扩容或降级等更进一步的运维能力。

压测环境

在梳理完压测场景后，就要确认压测链路是否完整或符合预期。从一个服务到另一个服务，是不是链路上每一个服务都要压到？下游服务如审计安全等是不是已经考虑到？压测过程中产生的脏数据是否会影响线上数据？可能还要细化到具体下游某个服务不参与压测，如何处理呢？以上种种问题，可能需要推动整个链路相关的业务方进行对应业务改造来适配压测流量，改造完后还要自测验证才能正式开始压测，下面讲一些重点问题，部分内容引用自文末的参考资料。

脏数据问题

不参与压测的服务如何处理

image

可以独立部署一套线下环境进行压测。在不影响线上环境的前提下，确保机房，网络，存储，上下游服务与线上保持一致，部署一套独立的环境进行测试，机器与线上隔离，机器出问题不会影响线上。这种方式压测只是针对较少的几个系统进行，因为很难把整个链路所有系统都独立再部署一套，所以应用范围有限。

备注：上游、下游如何定义？RFC 2616

Upstream and downstream describe the flow of a message: all messages flow from upstream to downstream.

下游的输入来自于上游的输出，假设有服务A、B，A调用了B（或者说A依赖B），那B就是A的上游，A就是B的下游，因为A的输入来自于B的输出（A调用了B，获取B的输出）。

更简单地理解，越接近用户的东西，越是下游。

更常见的方法是直接使用线上环境压测，在机器负载低的时间段（如深夜）人工发起或定时发起压测。

压测监控体系

确认好压测流程的技术支持和Mock数据的支持后，还要确认压测链路的监控体系是否完整，一来方便在压测过程中及时发现问题，二来是为了积攒历史压测数据，三来顺便确认监控系统本身是否可靠且全部到位。一般监控项包括（也就是压测指标）：

压测数据

压测数据其实没什么神秘的，网上说什么按照业务模型产出数据，表达上做了过度抽象反而不好理解，其实意思就是按照业务核心场景将所需要的数据构造出来。关键是要如何科学地模拟线上数据分布，引用文末参考资料，阿里双十一大促中有如下的业务流量漏斗模型，需要给不同场景科学地分配流量比例，这个比例是分析出来的而不是拍脑袋的。可以想象，阿里大促的流量不可能全部最后都走到付款流程，必然很多流量会在前面的流程就结束了，也就意味着，你把全部压测数据都构造成【走到付款场景】的话，你的压测结果是不准确的。

image

为了更好模拟线上真实的用户使用场景和数据，dump线上数据用来压测是很常见的手段，有两种简单思路：

数据dump下来是不能直接用的，一来没加压测标记会污染线上数据，二来涉及用户隐私数据。可以将线上数据作为数据源，经过采集、过滤、脱敏等操作后转变为压测数据，注意点有：

  1. 确保数据已添加压测标记

  2. 账户数据要提前完成登录认证等准备工作

  3. 数据要尽可能跟真实数据保持一致，比如，价格，图片等

  4. 数据是否有不同设备型号等特殊要求

  5. 尽量保持和线上相同缓存的命中率

  6. 其他业务特性上的特殊要求……

压测过程

基本思路跟做质量保障是一样的，从细粒度开始慢慢集成到整个大系统，就像单测->接口测试->集成测试，压测也是先从简单的开始，一步一步走向全资源全链路，可以参考过程：单接口单机->单接口1/4资源->场景化1/4资源->全量资源压测->拨测。

单接口单机

在单核（或物理资源少）机器上部署单个服务，排除外部链路、网络等因素，得出自身服务的单核性能情况（单位QPS/core），后续根据此单核性能指标结合压测目标值进行扩容。另外由于是压的单接口单机，无其他接口请求影响，上下游在足够资源的情况下也不会造成瓶颈，所以能确保服务的性能真实值。

单接口单机可以在正式开始大规模压测前提前发现问题，方便RD做针对的性能优化并快速检验优化效果。一部分问题会先在单接口单机压测环节中发现，而一些隐藏得更深的问题，需要延后到全链路大流量压测才能暴露。

单接口1/4资源

单接口单机压测环节，服务端已经完成了部分性能优化，接下来可以进入单接口1/4资源压测，这样是为了验证在单接口单机压测中得到的单核性能数据，在扩容1/4资源下性能是否会线性增长，是否存在性能损耗以及定位损耗源。

场景化1/4资源

单接口压测局限很明显，场景化压测由于引入了上下游服务的其他接口的因素，可以发现单接口压测无法发现的问题，更接近线上用户场景。

全量资源全链路

全部资源到位后，预估的线上压力是否能承受，这一步也是内网压测过程的最后一步。

拨测

除了做内网压测，还要进行拨测验证用户从客户端到服务端的整个带宽资源是否满足预期，内网压测已经确认了业务性能是否达标，因此拨测可以只选择了一个场景进行验证即可。（简单来说拨测相当于压测cdn，检查各地cdn节点资源是否充足）

压测策略

压测过程也要提前规划好，然后加入一定的人工策略调整。阿里大促还会有预热环节，预先跑一部分流量使得该缓存的数据提前缓存起来。正式压测时细分有几种压测策略，引用自文末参考资料：

除了关注前面讲到的指标外，还需要关注各机房流量是否均匀（若不均匀要确认负载均衡是否work）。

压测收尾

发压环节的结束并不代表压测就到此为止。

数据清理

如果使用了影子表，可能收尾工作会简单一些，只需要下掉影子表即可。如果数据直接落到了线上数据库，可能一大堆压测数据要清理，压测时会对数据染色（比如指定测试账号或流量携带压测标记），逐层透传，最后根据标志识别删除。

常见问题

举例一些可能会发现的典型问题：

  1. 存在多余的http header，导致额外带宽占用

  2. spin_lock对RT影响大，优化锁的方式

  3. 调整nginx worker数量可提高性能

  4. 不恰当的长链接数

  5. 代码实现上对象没有较好复用

  6. cache命中率不符预期

  7. 业务流程上存在冗余

  8. 缺少一层cache

  9. 响应码or错误码可能要继续规范

  10. 下游服务资源不足（其他监控、存储）

  11. 内部系统对压测的限流，需要变更配置或者协商解除限制

……

压测总结

给出一个完整的压测过程例子：

  1. 确定本次的压测目标，预估各项指标的达标值

  2. 根据服务接口的优先级和使用场景，确认出需要压测的接口

  3. 梳理压测链路上的服务，确认链路完整性

  4. 针对压测链路设计的服务进行压测改造

  5. 准备压测数据，确认压测策略

  6. 开始压测，监控各项指标，多轮压测检验性能优化效果

  7. 压测环境清理

  8. 压测总结报告输出

压测最终应该输出一份报告总结，其实也就是把整个压测方案、过程、结论记录下来，写明压测目标、压测接口、压测数据、压测结论，给出发现的问题并提供优化方案。往往在压测报告完成时，性能问题已经基本被解决了，报告的意义在于梳理前面的整个流程，给后续的压测提供经验指导。

转自：https://maimai.cn/article/detail?fid=1496907676&efid=mEN-ylg-2f_k24kjcom0kQ&use_rn=1

上一篇下一篇

猜你喜欢

热点阅读