概述
性能测试按照不同视角,可以分为以下几类:
a. 用户视角的性能
用户角度感受到的网站响应速度的快和慢。从用户在浏览器输入网址/打开应用, 到整个页面呈现给用户的耗时。包含了用户端发送请求,服务端收到并执行请求,返回 请求,客户端收到之后渲染的总时间。
b.开发人员视角的性能
包括系统吞吐量,并发处理能力,系统稳定性,响应延迟等。如果发现有不满足要求的地方,需要定位出问题所在,并给出解决方案。
c.运维
主要关注基础设施性能和资源利用率,如网络运营商带宽能力,服务器应急配置, 数据中心网络架构,服务器和网络带宽的资源利用率等。
为什么要做接口压力测试
1.清楚自己所提供的接口性能是多少
2.判断出系统可能存在的问题(代码,DB,cache,系统配置,容量等),提前解决
3.为设置接口的限流/熔断做参考
接口压力测试的局限性
接口压力测试只注重单业务的接口性能,进行压测的时候,只关注个别接口的性能。
接口大部分时间是在线下进行,可能线上线下机器配置不一样,而且线上同时在进 行着各种不同的业务。
因此在线下进行接口压力测试的结果,只能作为线上配置的一个参考值。
谁来做接口压力测试
对接口比较熟悉的开发人员来做,这样有以下好处:1.对接口实现比较了解,对接口中潜在的问题有一定的预判2.比较容易对接口进行优化(业务逻辑层面和技术层面)。
如何做接口压力测试
通常使用 Jmeter ,loadRunner, Metersphere 等进行压力测试。
如何设计接口压力测试方案
1.如何确定并发数:
可以通过尝试的方式。第一次压测的时候,可以设置自己预期接口需要达到的并发 数,进行压力测试。然后通过二分法进行调整。
举例:如果期望的并发数是 100 ,第一次压测并发数设置为 100 ,如果系统没有 压力,第二次并发就尝试设置为 200。如果系统有压力,下次就设置为 150。通过逐渐 尝试的方式,找出当前接口的并发阈值。
2.如何确定总请求次数:
有时候单纯的通过并发数并不能完全发现系统的压力状况,因为并发数只能测出系统的处理能力。
但是有时随着长时间的调用,系统可能会出现其他问题。比如:随着数据量的增多, 存储磁盘满了、内存缓存用光,缓存服务使用磁盘缓存而拖慢系统等情况。
为了避免这种情况,可以尝试用现有线上业务每天产生的数量乘以一定的天数(天 数的大小视业务的具体情况而定,推荐 180 天以上),作为接口压力测试的总请求次数。
3.接口压力测试数据的选取:
通常随机选择数据。但是要注意重复进行压力测试对性能的影响。比如:
第一次压测的 Id 是从 2500W 到 2600W 之间选择的,下次用同样的 Id 范围做压 测的时候,如果接口实现中有缓存,则会很大程度影响压力测试的结果,对压力测试的 解读时候,要考虑到这个因素。
另外,使用不存在的 Id 去进行压测,结果并没有太大意义。
压力测试报告应该包含哪些结果
1.接口压力测试结果
2.服务器压力
每次接口压力测试时,接口所在服务的服务器 cpu/jvm 使用率历史记录,jvm堆大
小,响应时长图 (借助 pinpoint 查看),cpu load 值(top 命令),gc 信息等。
如何解读压力测试的结果
1.对于接口压力测试结果:
关注响应时间是否符合要求,响应时间(前 99%) 是不是在可允许的范围内。最大值是多少,是否可以容忍。通常来说,错误百分比应该为 0。
2.对于服务器压力:
看 cpu 使用率是否在可接受范围内,jvm 堆大小是否变化频繁,是否有 fullGC。Young GC 耗时,CPU load 值是否在可接受范围内。响应时长图是否平滑(如果有毛 刺现象,需要找出原因)。
如何根据测试结果定位性能问题
1.响应时间不符合要求:
通过 pinpoint 观察调用链,找出耗时比较长的步骤,进行优化
2.并发数达不到要求,可以从以下几个方面进行考虑:
a 是否发生系统依赖资源争用(比如:数据库连接,业务处理线程数等)b 业务流程/代码性能是否可以优化
c 在运行的过程中是否频繁 GC
- CPU 使用率过高:
a 在运行的过程中是否频繁 GC
b 是否发生过多的线程切换
c 程序中是否有比较耗 cpu 的代码
全链路:pinpoint
修复性能问题
除了只可能在极端压力测试情况下会发生的性能问题,并且修复代价过大的问题可 以不进行修复(但是要在压力测试报告中体现出来此问题,以及解决方案),其他问题 都必须进行修复。
其他
如果没有专门的接口压力测试环境,记得做完接口压力测试之后,将测试数据清除(缓存,数据库,消息中间件中未消费完毕的消息等)
一站式收获前沿测试开发技术、先进测试管理经验,结识业界大咖精英
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。