需求
下面有3个场景，思考一下在jmeter里面如何设计
场景1：有一个项目，500用户同时登录，响应时间能达到多少
场景2：考勤打卡，最大吞吐量能达到多少（每秒最大能完成多少笔打卡业务）
场景3：银行业务，如果需要支持1分钟内完成3000笔取款操作，平均每秒能支持多少用户同时取款完成
负载模式
性能测试中的负载模式有两种。
第一种是并发用户模式（虚拟用户模式）
并发用户是指虚拟并发用户数，从业务角度，也可以理解为同时在线的用户数。从客户端的角度出发，摸底业务系统各节点能同时承载的在线用户数，可以使用该模式设置目标并发，也就是 jmeter 里面的线程数。
第二种是RPS 模式（吞吐量模式）
RPS（Requests Per Second）是指每秒请求数。RPS 模式即“吞吐量模式”，通过设置每秒发出的请求数，从服务端的角度出发，直接衡量系统的吞吐能力。
场景设计
场景一分析
场景一就是典型的并发用户模式。
我们在用jmeter设计第一种场景的时候，可以用线程数去模拟并发用户。如下图
设置500线程去模拟500用户；一次迭代表示每个线程的请求只发起一次；集合点500表示这500线程将在同一时间发起请求
场景二分析
场景二就是典型的吞吐量模式了。
为什么要设计这种模式呢？因为我们通常谈到压力都是从客户端去考虑的，也就是先知道并发用户数有多少，然后再去发起压力。但是如果不知道并发数的话，我们是不是就没有办法去测试了?所以后来从阿里衍生出了一个RPS模式，就是绕过并发数的计算，直接通过吞吐量去直接衡量服务端的性能。吞吐量是衡量系统性能的唯一标准。
设计第二种场景的时候，我们就需要考虑吞吐量了。我们一般通过负载测试来找到吞吐量的拐点。
负载测试：持续稳定地增加系统的负载，测试系统性能的变化，找出系统瓶颈和性能拐点
如果用rps压力模式的话，这里所谓的增加系统负载，就是指的增加每秒请求数。如下图rps定时器
下图表示我在60s内将rps稳定的加到400/s
下图表示监听到的tps数据
场景三分析
场景三其实也是一种吞吐量模式，但是这里的吞吐量不再是完成的请求数，而是完成的业务数，或者叫事物
业务时间
支撑1分钟内的3000笔取款操作，这里的意思就是1分钟内完成3000笔取款的业务。怎么才算完成业务呢？事实上我们一笔取款机取款业务的完成时间需要从打开页面发起请求开始计算，到响应完成，然后取款机给出结果让用户看到为止，中间还要包括思考时间。所以单笔取款业务时间=浏览器渲染时间+连接时间+思考时间+服务处理时间
平均并发数
我们知道了一分钟完成3000笔业务的需求，业务时间也可以计算出来。那么平均并发数是什么意思？这里的平均并发数指的是平均每秒有多少用户同时取款完成，才能达到这个一分钟3000的业务量。假设我的服务处理+浏览器渲染时间是2s，思考时间是8s。计算平均并发数的公式如下：
平均并发=（单笔业务时间*业务总量）/业务时间= （10 X 3000）/60=500/s
也就是说，平均每秒有500个用户取款，能达到我的预期业务量场景设计如下图
