压测相关

如何确定压测指标？要压多少线程？

  • 一般有需求文档，将里面的一些需求量化为性能指标值，也是我们的性能指标预期结果
  • 比如会提前确定并发量（即线程数）、预期 TPS、响应时间
  • 一般并发数会根据系统来确定，如果是新系统就会要求业务部门进行一个初步的估算，然后从基准测试开始，使用阶梯加压的方式，测试支持的最大并发量，即达到某个并发量之后，TPS 不再上升出现拐点了，达到瓶颈，确定最大并发量
  • 如果是旧系统，会以最大在线用户的10% 来做并发量

    TPS 上不去会是什么原因？

  1. 网络带宽：压测中，需要进行模拟并发请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，就会造成网络资源竞争，间接导致服务端接收到的请求数达不到服务端的处理能力上限
  2. 硬件资源：包括 CPU 配置、CPU 使用率、内存占用率、磁盘 I/O
  3. 压测脚本：压测脚本的参数配置有问题，也会间接影响测试结果，比如设置的线程数不如预期
  4. 压力机：
    1. 压力机上的 Jmeter 配置的堆内存不足，这样 Jmeter 在运行时容易出现性能瓶颈
    2. 又或者需要模拟的并发用户数超过单台压力机的负载量，就会影响 TPS，这个时候就需要分布式压测了
  5. 业务逻辑：业务耦合度高，逻辑复杂，导致完成一个完整事务的时间会延长
  6. 通信连接机制：串行、并行、长连接、短连接、管道连接也会间接对 TPS 有影响
  7. 数据库配置：高并发情况下，请求需要频繁读写数据库，且需要操作多张表的时候，如果数据库的最大连接数不够，或者没有索引、主从分离、读写分离等，就会导致数据库事务处理过慢，影响到 TPS
  8. 系统架构：如果有缓存服务，缓存服务器配置、缓存命中率、缓存穿透以及缓存过期都会影响测试结果
  9. 连接池：
    1. 可用的连接数太少，造成请求等待
    2. 连接池一般分为服务器连接池（比如 Tomcat）和数据库连接池（最大允许连接数）

  10. 垃圾回收机制：如果垃圾回收机制频繁触发对 TPS 也会有一定的影响

    TSP没到，但程序没法再优化了，怎么办？

    横向扩容，就是增加机器数量，因为纵向扩容是有上限的，一台机器可能配置最高就这样了，而且程序无法继续优化，但是机器数量可以不断上升

    JMeter 相关

    JMeter 参数化的5种方法

  11. 配置元件-用户自定义变量

  12. 配置元件-CSV 文件配置元件，通过 csv 文件写测试用例，然后读取后做参数化
  13. 前置处理器-用户参数
  14. 前置处理器-JDBC 前置脚本，通过数据库读取数据进行参数化
  15. 函数-CSVRead，也是读取 csv 测试用例文件

    用户自定义变量和用户参数的区别？

  • 用户自定义变量是配置元件，全局只生效一次，即使变量值是随机数也只会取一次
  • 用户参数是前置处理器，每请求一次都会重新执行一次，即变量值是随机数的话每次都会取新的值