jmeter性能测试笔记1-性能测试基础概念

什么是性能

应用到软件上，性能可以从以下方面考虑：

1. 系统响应时间：页面要加载很久才加载出来
2. 短信下发时间：验证码要一分钟才拿到，验证码延时超过有效期
3. 系统稳定运行：项目在运行一段时间后出现宕机或是进程被杀，通过查日志发现可能是内存溢出被系统强制杀进程
4. 代码高效运行：不同的代码不同的方法运行出来的时间不一样，考虑开发人员的功底
5. SQL高效查询：查询数据库没有加索引、加的全局索引、做了慢查询、触发锁导致线程阻塞
6. 硬件资源充足：内存不够、机器四核才满足运行、磁盘空间不足、带宽（1000M带宽、下行速度100m、上行4m）

从测试角度考虑软件性能：

• 从用户角度发现问题
• 从开发角度分析问题, 技术可行性
• 从运维角度预估问题, 容量规划

什么是性能测试

通过技术手段，发现性能问题，解决性能问题

应用领域

从应用领域来看，可以分为4块：

1. 能力验证：通过验证，向第三方声明系统所具有的能力
   • 验证过程：使用工具验证，jmeter、loadrunner
   • 声明能力：
     • 响应时间：500并发，95%响应时间不超过2s；持续运行1h，95%响应时间不超过2s
     • 最大tps达到800/s
   • 结果输出：
     • 性能方案：性能用例、性能计划、性能需求
     • 性能报告
     • 性能优化结果
2. 性能分析
   • 压力机：内存问题、长连接问题、tcp内核配置
   • 网络：带宽、QoS资源
   • 中间件：tomcat（连接数、线程、backlog）、nginx（连接配置、资源配置）、redis、apache
   • mysql：连接、缓存、索引、日志
   • 服务器：内存、磁盘、带宽、cpu
   • 应用：java、golang、python
   • 错误
     • 连接错误：connection timeout、connection reset peer、socket refused、read timeout、response timeout、address already in use【tcp端口占用】、socket IO read fully
     • 内存错误：out of memory【内存溢出】
     • 网关错误：防火墙，白名单，ddos拦截
3. 性能调优：和性能分析连在一起，分析发现问题后进行优化
4. 容量规划
   • 考虑用户发展，业务增量对资源的压力
   • 为机器扩容收集理论依据

场景分类

从场景分类，即性能测试类型分类：

1. 并发测试
   • 并发用户/请求：同时触发某个请求，或者做某个动作，强调的是某个点上的压力
     • 瞬时并发：500用户，1s内同时点击查询
     • 测试资源争用，锁争用，线程安全
     • 区间并发：100万用户，8小时内访问服务
   • 并发业务：多条业务流同时进行
2. 负载测试：持续不断的增加压力，测试服务端性能瓶颈，找到拐点，找到对比值
   • 压力：用户、请求
   • 瓶颈：tps、资源使用
3. 压力测试：维持一个压力区间，持续不断的运行，暴露出隐藏的问题【内存泄露】
   • 维持tps峰值持续运行
   • 维持资源饱和持续运行
4. 破坏压力测试：快速暴露异常
5. 失效恢复：压力测试异常之后，系统能够恢复正常
6. 容量测试：系统需要在1h内完成5万笔业务【单业务/混合业务】总量，需要设计多少线程运行？

场景模型

1. 预期指标测试：从需求和设计文档中提取明确的性能指标，通常以单用户或并发用户测试为主
2. 用户并发测试：模拟大量的用户数来对系统加压，通过对用户数和相关场景的调整来发现系统瓶颈
3. 稳定性测试：持续维持一定的高压，发掘隐藏的性能问题，属于用户并发测试的延伸
4. 数据量测试：
   • 稳定的业务数据：模拟用户工作时的数据量，测试用户数据和业务数据较大时的查询性能和系统运行状况
   • 积压的消息数据：测试生产者积压一定数据量后消费者能否正常运行
     • 生产者积压消息
     • 消费者批量消费
     • 消息协议：mqtt（应表会传网接物、在应用层，头部2个字节）、amqp
     • 消息队列【MQ】
     • 消息中间件：active、rabbit、kafaka、EMQ
     • 生产者【publisher】
     • 消费者【subscriber】
     • 消费模式：主题【topic】、队列【queen】
5. 网络测试：
   • 弱网测试
   • 带宽测试

结果有效性

1. 稳定的环境：网络环境、软硬件环境
2. 充足的数据
3. 合理的场景：用户访问时间、用户访问频率、业务访问比例、用户思考时间

性能测试误区

1. 性能测试就是压接口/性能测试就是做并发

性能测试包括：

• 前端性能测试：web端（Dom框架、加载js/css脚本、加载静态资源、页面渲染、GPU，GC），H5
• 接口性能测试：连接时间+处理时间+回传时间，长连接、短连接
• 消息性能测试：MQ、MQTT、消息吞吐量、积压能力、消费能力、消费策略（业务解耦、流量削峰）
• SQL性能测试：数据库缓存，sql执行效率，索引
• 资源消耗测试：CPU使用率，网络IO，磁盘IO

---

2. 只要加线程，TPS就一定会升高

不一定，负载在增加的过程中TPS可能会下降，服务端的性能肯定是有上限有瓶颈的

---

3. 线程上千，数据一条

• 用户数据
• 业务数据

要保证充足的数据才能保证有效的结果

---

4. 脚本打印各种日志

• 数据在内核做读写：频繁的数据读写会导致cpu的sys利用率很高，影响应用执行
• 数据读写需要和磁盘做交互：导致IOwait变高，同样影响cpu利用率
• 生产日志保持为error

---

5. 结果是不是有效不关心

• 稳定的环境：
  • 硬件环境：网络（规避网络高峰期、带宽要稳定）、硬件资源（网卡，cpu，内存，磁盘）
  • 软件环境：软件的版本
• 合理的数据
• 真实的场景（容量测试）：用户时间段、用户访问量、用户比例值
• 有效的结果

---

6. 项目上线之后跟我没关系

• 功能逐渐稳定，性能问题逐渐暴露
• 用户越来越多，项目运行时间越来越长，稳定性存在问题
• 上线之后对性能做持续性的监听：zabbix、Prometheus、grafana