接口性能测试案例分析

▌概述

性能测试按照不同视角，可以分为以下几类:

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

3. CPU 使用率过高:
a 在运行的过程中是否频繁 GC
b 是否发生过多的线程切换
c 程序中是否有比较耗 cpu 的代码

全链路:pinpoint

▌修复性能问题

除了只可能在极端压力测试情况下会发生的性能问题，并且修复代价过大的问题可以不进行修复(但是要在压力测试报告中体现出来此问题，以及解决方案)，其他问题都必须进行修复。

▌其他

如果没有专门的接口压力测试环境，记得做完接口压力测试之后，将测试数据清除(缓存，数据库，消息中间件中未消费完毕的消息等)

如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！

最后基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等配套学习资源在下方公众号免费获取~

接口性能测试案例分析相关推荐

【案例分析】分布式系统的接口幂等性设计！
概念幂等性, Idempotence, 这个词来源自数学领域, 百科上一元运算的幂等性解释如下:设 f 为一由 {x} 映射至 {x} 的一元运算, 则 f 为幂等的, 当对于所有在 {x} 内的 ...
51单片机控制系统的人机交互接口设计【51单片机与LED数码管的动态显示接口案例分析】
本章节利用Keil uVision5和ISIS 7 Professional两个软件来进行仿真实验. [例]运用51单片机实现8位8段数码管的动态显示,LED数码管的段选数据由51单片机的P0口控制, ...
阿里Java学习路线：阶段 1：Java语言基础－Java面向对象编程：第21章：抽象类与接口应用：课时94：案例分析二（绘图处理）
案例分析二考虑一个表示绘图的标准,并且可以根据不同的图形来进行绘制: interface IGraphical { // 定义绘图标准public void paint() ; // 绘图 } cl ...
MIPI DPHY接口(基于Xilinx FPGA实现)案例分析
大家好,我是"FPGA功夫熊猫",这次分享一个在Xilinx FPGA实现MIPI DPHY接口的案例(包括CIS协议层).截止目前为止,Xilinx仅在Ultrascale+及其 ...
JAVA应用开发MQ实战最佳实践——Series2：消息队列RocketMQ性能测试案例
简介:JAVA应用开发MQ实战最佳实践--Series2:消息队列RocketMQ性能测试案例往期内容 JAVA应用开发MQ实战最佳实践--Series1:RocketMQ综述及代码设计 1. 消息 ...
《深入理解JVM.2nd》笔记（五）：调优案例分析与实战
文章目录概念案例分析高性能硬件上的程序部署策略情景再现1 问题分析1 关于Full GC 使用64位JDK来管理大内存可能遇到问题建立逻辑集群使用逻辑集群可能遇到的问题最后解决方案集群 ...
消息队列RocketMQ性能测试案例
1. 消息队列RocketMQ性能测试案例 1.1 RocketMQ测试分析客户场景,信息共享交换平台: 1.交换平台需支持每秒万级别数据传输 2.实现跨路段.跨部门.跨行业.跨区域信息即时共享,做 ...
Linux 性能测试与分析-转
转自http://blog.sina.com.cn/s/blog_71ad0d3f01019uzl.html Linux 性能测试与分析 Revision History Version Date A ...
linux 定时任务数量性能,Linux 性能测试与分析
Linux 性能测试与分析 Revision History VersionDateAuthorDescription 1.12011/6/23添加CPU分析 1.22012/2/20添加MEM,IO ...
架构设计案例分析-高速公路收费运营管理平台
本文旨在通过对某省高速公路联网收费运营管理平台的架构设计过程进行案例分析,描述架构设计的决策过程. 1.业务背景某省的高速公路分为近百个路段,不同的路段归属不同的公司建设与运营,造成了车辆在跨越不同 ...

接口性能测试案例分析

接口性能测试案例分析相关推荐

最新文章

热门文章