（二）性能测试理论知识-并发

首先感谢各位前辈的博客分享，把点滴学测试过程整理成文字，与感兴趣者分享，勿多怪咎。

• 并发

1. 相对并发
2. 绝对并发
3. 线程
4. TPS
5. 用户数

---

不同并发

• 相对并发

　　指在一个时间段内发生的事情

       jmeter又如何实现相对并发的呢？一般采用线程组实现相对并发，在jmeter中的测试计划去添加线程组，设置线程属性。

　　（1）新增线程组

 　　（2）线程组界面配置详解

　　名称：定义线程组名称，若只有一个线程组，默认即可。
　　注释：描述线程组注释，可为空。
　　在取样器错误后要执行的动作：取样器发生错误要执行哪个动作，包含继续、启动下一进程循环、停止线程、停止测试、立即停止测试五个动作：

1. 继续：取样器发生错误，忽略错误，继续执行。
2. 启动下一进程循环：取样器发生错误，忽略错误停止当前线程循环，执行下一个循环。
3. 停止线程：当前线程运行完毕后，停止所有线程
4. 停止测试：停止测试计划，如果一个测试计划下有多个线程组，那么所有线程组都会停止
5. 立即停止测试：整个测试计划会立即停止运行　　

　　线程数：设置线程数，可以在测试计划的用户自定义变量中设置变量，在这里引用测试计划的变量 ${uesrs}
　　ramp-up时间： 设置启动所有线程需要的时间，我需要启动10个线程，并且10s启动一个线程，所以我的ramp up的值就是10*10=100s。我需要启动30个线程，并且设置的ramp up的值是120s，那我就是120/30=4s每4秒启动一个线程。

　　循环次数：设置线程组中的每个线程循环次数
　　永远：勾选此项表示线程组中的线程永久执行下去
　　same user on each iteration：每次迭代使用相同的线程
　　延迟创建线程直到需要：如果勾选了此选项，那么线程只会在合适的需要用到的时候创建
　　调度器：线程调度器包含持续时间、启动延迟两个选项

1. 持续时间：设置线程组运行多长时间，单位是秒
2. 启动延迟：设置线程启动延时时间，单位是秒

　　相对路径的实际案例。

　　（1）之内启动10个线程，其对应的相对并发为5（线程数/启动时间），在没有添加其他逻辑控制器或定时器的情况下，线程属性中设置循环次数为3次，则sampler总共执行30次（线程数*循环次数）

　　（2）使用表格察看运行结果：每个线程都会运行3次

• 绝对并发

　　指在同一时刻发生的事情

　　jmeter又如何实现绝对并发的呢？一般采用同步定时器（Synchronizing Timer）实现绝对并发，也就是同一个时刻达到了某一集合点才发出请求。

　　举个例子：将一筐的鸡蛋共188个，全部分发在容量为10的蛋托上，当蛋托上凑上10个便可以打包售卖。这里的188个鸡蛋就相对于jmeter中的线程数（用户数），容量10就是集合点数，即绝对并发数，剩下的8个鸡蛋无法构成集合点数，可设置超时时间不再等待聚积成10个。

　　注意：使用同步定时器做性能测试时，聚合报告中的响应时间一般会大于接口真实的响应时间，可以通过其他的监控工具查看接口真实的响应时间，将Synchronizing Timer放在对应的sampler下，Number of Simultaneous Users to Group by：集合点数，集合到对应的用户量才发送请求，要求设置的值不能大于线程数，Timeout in milliseconds：等待超时时间，在指定的毫秒时间内没达到集合点数将停止等待（并非终止运行），默认值为0表示无超时时间，一般超时时间> 请求集合数量 * 1000 / (线程数 / 启动时间)

1. 设置集合点数：2，超时时间>2*1000/(10/2)=400ms

　　运行

　　2.设置集合点数：7，超时时间：0

　　运行结果：剩下2个请求，无法构成7个集合数，导致一直等待。点击stop剩下2个请求运行后结束执行 

　　3.设置集合点数：7，超时时间：1500 

　　运行：剩下2个请求，无法构成7个集合数，通过日志可以看到等待时间超过了1500ms，执行这两个请求后将终止运行 

　　4.设置集合点数：20>10（线程数），超时时间0，将无法发送请求。点击stop会将30次请求全部执行，并不能按20个绝对并发执行 

• 线程

　　 线程组：就是一个线程组，里面有若干个请求。

　　 线程：一个线程就是一个“虚拟用户”。　

　　例如：1个线程组里面有10个请求，线程数为10个，跑完后得到：

　　理解为：(10个线程数)10个人，每个人都要跑这10个请求，所以：10*10=100：

　　并发数：100；线程数：10；

　　PS：线程组也可以看作是一个虚拟用户组。线程组中的每一个线程都可以理解为一个虚拟用户。

• TPS

　　Transactions Per Second（每秒传输的事物处理个数），即服务器每秒处理的事务数。TPS包括一条消息入和一条消息出，加上一次用户数据库访问。执行一次事务（包括请求、请求服务器、等待服务器返回等等，比如一个TPS事务，可能触发3个QPS请求）

　　一个接口一秒钟能承受50个并发，不代表可以有50个吞吐量。

　　吞吐量与系统性能息息相关。

　　设置长时间跑接口，比如1秒50并发，持续60秒——发现实际接口请求数1461个，时间60秒，TPS参数较稳定。

　　TPS=请求数/时间，TPS大概在23左右，所以当前这个接口，系统能处理的事务在23个左右。

　　工作中，一般把TPS当成并发，也就是1s内有多少完成的事务数，根据上面的例子，就是TPS=23/s

• 用户数

　　在线用户数：已登录系统的用户数。

　　并发用户数：同时操作的用户数，一般测试的时候并发用户取在线用户的20%-30%进行测试，在线用户数不是所有用户都正在并发交互，如一个网页，可能有20%是在浏览，20%在提交事务，50%在挂着没操作，所以真正的并发的用户不多。

　　系统用户数：系统注册用户数。

原文链接：https://www.cnblogs.com/lucky-happy/p/10537993.html