压测的目的
压力测试是对系统不断施加压力，来获得系统最大服务能力的测试。
一般而言，只有在系统基础功能测试验证完成、系统趋于稳定的情况下，才会进行压力测试。
当负载逐渐增加时，观察系统各项性能指标的变化情况是否有异常
当负载逐渐增加时，观察系统各项性能指标的变化情况是否有异常
（如：使用mysql存储的系统，高并发情况下，数据库读写速度慢，可以考虑增加数据库中间件，加缓存等；使用redis存储的系统，通常存储不会制约性能，但在高并发情况下，Redis的吞吐量非常大，这时候就需要考虑增加网络带宽来提高性能。）
系统在高并发情况下是否会报错，进程是否会挂掉
测试在系统某个方面达到瓶颈时，系统可以支持的最大负载
压测的关注点
压测的指标通常有tps、响应时间、错误率等，服务器资源监控cpu、内存、 I/O。
指标的来源：用户对各项指标提出明确需求，如果用户没有提出性能指标则根据用户需求和自己的经验来预估。
观察服务器的各种异常情况
响应变慢
返回4XX、5XX错误码
服务器无响应
服务器crash等
压测指标
**注：**并发用户数≠每秒请求数
比如说：在性能测试工具或者脚本中设置了100并发用户数后，并不是每秒100个请求发给服务器。每秒发出多少请求只跟服务器返回响应的速度有关。如果用户在50ms内就收到了响应，那么它会立即发出第二个请求；而如果要一直等待3秒才能得到响应，它将会一直等到收到响应后才发出第二个请求。所以，只有当响应时间恰好是1秒时，并发用户数才会等于每秒请求数；否则每秒请求数可能大于并发用户数或小于并发用户数。
在并发数达到一定的数量后，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等其它消耗导致性能下降。
压测步骤
1.参数化是使用指定数据源中的值来替换脚本中的参数，可以更加真实的模拟现实应用。
2.压测中的场景可以理解为功能测试中的用例，合理的场景设计才会更好地发现系统的性能缺陷。
3、执行压测场景后，若分析结果没有达到预期，提出优化方案，优化后再重新测试。
场景设计涉及要素
1.并发用户数是多少？
2.需要包含哪些接口请求，各个接口请求的占比是多少？比如，70%的用户在请求获取配置的接口，30%的用户在请求上报结果接口。
3.各个操作之间的等待时间是多少？
4.测试刚开始时，以什么样的速率来添加并发用户？比如，每秒增加5个并发用户。
5.测试结束时，以什么样的速率来减少并发用户？比如，每秒减少5个并发用户。
6.达到最大并发用户数后持续多长时间？
7.需要监控哪些被测服务器的哪些指标？
8.脚本出错时的处理方式是什么？比如，错误率达到 10% 时，自动停止该脚本。
9.需要使用多少台施压机才能使被压机器产生足够的压力？
场景设计分析实例
1000台客户机，每台客户机间隔2s上报一次心跳（获取任务），服务端每秒向每个客户端下发一个任务，每个任务执行完成后向服务端上报result和message
服务器：lvs 6台 4核8G Linux
数据库：redis、mysql
场景分析：共包含3个接口
预估tps：500+1000+1000=2500服务器每秒应能支持2500个请求
TPS=并发数/响应时间
接口平均响应时间：(1001+1502+400*2)/5=160ms
**并发数：**400
**操作顺序：**心跳（获取任务）->上报结果 ->上报其他信息
**需要监控信息：**服务器资源：CPU、内存、负载
**数据库：**mysql行锁时间、连接数、从库延时redis连接数、CPU使用率、内存
测试结果分析-确认问题
将测试结果与用户需求做比较，如果达不到用户需求，则需要对问题进行分析
常见问题分析
**优化前：**平均响应时间较长，Tps基本在1000左右，由于mysql操作占用较高的io，CPU大部分空闲，负载均在1左右。
**原因：**mysql的性能影响了服务的性能，由于mysql经常连到上海、深圳，所以会时慢时快。
**优化：**mysql都连到北京机房
**优化后：**tps达到2000左右，平均响应时间是优化前的二分之一，tps是优化前的二倍。
压测工具介绍
Jmeter脚本创建
BeanShell PreProcessor是一个前置处理器，它可以进行一些处理，比如执行一个算法并将结果存储到参数中。
响应断言：不符合断言的记为错误请求
设置压测任务的并发数、执行时间等
若未指定ramp-up period ，默认为零，将立即建立所有线程。假设ramp-up period 设置成T 秒， 全部线程数设置成N个， 将每隔T/N秒建立一个线程。
比如：使用10个线程，ramp-up period是100秒，每个线程会在上一个线程启动后10秒（100/10）启动
查看聚合报告
