概述
性能测试按照不同视角，可以分为以下几类:
用户角度感受到的网站响应速度的快和慢。从用户在浏览器输入网址/打开应用， 到整个页面呈现给用户的耗时。包含了用户端发送请求，服务端收到并执行请求，返回 请求，客户端收到之后渲染的总时间。
为什么要做接口压力测试
接口压力测试的局限性
接口压力测试只注重单业务的接口性能，进行压测的时候，只关注个别接口的性能。
接口大部分时间是在线下进行，可能线上线下机器配置不一样，而且线上同时在进 行着各种不同的业务。
因此在线下进行接口压力测试的结果，只能作为线上配置的一个参考值。
谁来做接口压力测试
对接口比较熟悉的开发人员来做，这样有以下好处:1.对接口实现比较了解，对接口中潜在的问题有一定的预判2.比较容易对接口进行优化(业务逻辑层面和技术层面)。
如何做接口压力测试
通常使用 Jmeter ，loadRunner, Metersphere 等进行压力测试。
如何设计接口压力测试方案
举例:如果期望的并发数是 100 ，第一次压测并发数设置为 100 ，如果系统没有 压力，第二次并发就尝试设置为 200。如果系统有压力，下次就设置为 150。通过逐渐 尝试的方式，找出当前接口的并发阈值。
但是有时随着长时间的调用，系统可能会出现其他问题。比如:随着数据量的增多， 存储磁盘满了、内存缓存用光，缓存服务使用磁盘缓存而拖慢系统等情况。
为了避免这种情况，可以尝试用现有线上业务每天产生的数量乘以一定的天数(天 数的大小视业务的具体情况而定，推荐 180 天以上)，作为接口压力测试的总请求次数。
第一次压测的 Id 是从 2500W 到 2600W 之间选择的，下次用同样的 Id 范围做压 测的时候，如果接口实现中有缓存，则会很大程度影响压力测试的结果，对压力测试的 解读时候，要考虑到这个因素。
另外，使用不存在的 Id 去进行压测，结果并没有太大意义。
压力测试报告应该包含哪些结果
小，响应时长图 (借助 pinpoint 查看)，cpu load 值(top 命令)，gc 信息等。
如何解读压力测试的结果
如何根据测试结果定位性能问题
- CPU 使用率过高:
a 在运行的过程中是否频繁 GC
b 是否发生过多的线程切换
c 程序中是否有比较耗 cpu 的代码
全链路:pinpoint
修复性能问题
除了只可能在极端压力测试情况下会发生的性能问题，并且修复代价过大的问题可 以不进行修复(但是要在压力测试报告中体现出来此问题，以及解决方案)，其他问题 都必须进行修复。
其他
如果没有专门的接口压力测试环境，记得做完接口压力测试之后，将测试数据清除(缓存，数据库，消息中间件中未消费完毕的消息等)
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/229114.html原文链接：https://javaforall.net
