jmeter使用Ultimate Thread Group线程组详细教程
一、Ultimate Thread Group字段解释
解释：
- Start Threads Count：启动多少线程
- Initial Delay,sec：延迟多少秒开始启动线程
- Startup Time,sec：启用{Start Threads Count} 个线程花费多少秒
- Hold Load For,sec：线程全部启动完成后再持续运行多少秒，在此期间，每个线程请求完一遍后会再次发起相同的请求，若有思考时间，则会间隔设定的思考时间后再发起
- Shutdown Time：在多少秒内将 {Start Threads Count} 个线程全部停掉
二、应用举例
1、不延迟：
2、延迟6秒开始启动线程：
3、通过多行设置实现梯度加压：
三、添加监听器（Active Threads Over Time）（单位时间内活动的线程数）
线程数与Ramp-Up时间
线程数就是我们设置是虚拟用户数，可以理解为1个线程，就是一个虚拟用户。
Ramp-Up时间 也就是启动时间，或者说是准备时间，比如我们设置线程数为10，那么这些用户不是一瞬间就来的，它需要有一个准备的时间。
线程数10， Ramp-Up时间设置为1秒，那么在1秒内会启动这些线程。
线程数10， Ramp-Up时间设置为2秒，那么在2秒内会启动这些线程。
设置线程数10， Ramp-Up时间设置为1秒
从上面结果看出在1秒内，线程全部启动完毕
设置线程数10， Ramp-Up时间设置为2秒
四、添加监听器（Response Times Over Time）（响应时间-随着时间推移）
RT 也就是平均响应时间(Reponse Time), 在聚合报告里面可以看平均值(单位是毫秒)，如果我们想查看更详细的报告，跟着每个时间段的平均响应时间。
添加-监听器-jp@gc - Response Times Over Time
压测后，先看聚合报告的平均值92毫秒
再看实时监控的平均响应时间
间隔时间:500ms (隔500ms，把这500ms收到的请求的平均响应时间标记红点显示在图表上)
它的红点是指这个间隔里面请求的平均响应时间
目的：拿请求耗时是为了用excel绘制柱形图
解决方法：jp@gc - Response Times Distribution
这种曲线图，在写性能报告的时候加上会显示更专业
原文地址https://www.cnblogs.com/yoyoketang/tag/jmeter/,转载请注明出处！
五、添加监听器（Response Times vs Threads）（响应时间-随着线程/用户增多）
六、添加监听器（Transactions per Second）（每秒事务数/每秒服务器处理客户端请求数）
TPS(Transaction Per Second) :每秒事务数，通常指每秒成功的事务数，性能测试中重要的综合性性能指标，代表着服务器的处理能力。一个事务是一个业务度量单位，有时一个事务会包括多个子操作，为了统计方便，会把着多个子操作记为一个事务。
TPS（Transaction per Second）定义：
tps是Transaction per Second的缩写，也就是事物数/秒。它是软件测试结果的测量单位，一个事物是指一个客户机向服务器发送请求饭后服务器做出反应的过程。
客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用时间和完成的事物数，最终利用这些信息来估计得分。
TPS（Transaction per Second）作用：
反映了系统在同一时间内处理业务的最大能力，这个数据越高，说明处理能力越强，描述（看到系统的TPS随着时间的变化逐渐变大，而在不到多少分钟的时候系统
每秒可以处理多少个事物。这里的最高值并不一定代表系统的最大处理能力，TPS会受到负载的影响，也会随着负载增加而逐渐增加，当系统进入繁忙期后，TPS会有所下降。）
TPS（Transaction per Second）局限性：
1、tps是从客户端角度审视服务器处理能力，并不是说TPS可以达到什么程度就能支持多少并发（例如：一个业务100个交易，另一个业务10个交易）。
2、TPS = 脚本运行期间所有事物总数 / 脚本运行时长，如果使用集合点策略，在脚本执行前的等待时间过程中，服务器没有处理事务，那么这个时候的TPS和理想中的结果不一致。
3、限制TPS的原因：服务器本身性能、代码结构、客户端施加的压力以及网卡等。
TPS（Transaction per Second）与响应时间的关系：
1、TPS和响应时间在理想状态下的额定值。如果20个入口，并发数只有10的时候，TPS就是10，而响应时间始终都是1，说明并发不够，需要增加并发数达到TPS的峰值。
2、如果增加到100并发，则造成了线程等待，引起平均响应时间从 1 秒变成 3 秒，TPS也从20下降到9；TPS和响应时间都是单独计算出来的，两者不是互相计算出来的。
3、响应时间和TPS在宏观上是反比的关系，但是两者之间没有直接关系。
TPS（Transaction per Second）在性能测试中的作用：
1、一个系统的吞吐量（承压能力）与request 对CPU的消耗、外部接口、IO等紧密关联。单个request对CPU消耗越高，外部系统接口、IO营销速度越慢，系统吞吐能力越低，反之越高。
2、系统吞吐量几个重要参数：TPS、并发数、响应时间（TPS = 并发数 / 平均响应时间）
3、利用TPS计算系统最高日吞吐量；
4、找出系统最高TPS和日PV，这两个要素有相对比较稳定的关系。
5、通过压力测试或者经营评估，得出最高TPS，然后跟进1的关系，计算出系统最高日吞吐量。例如：B2B中文和淘宝对客户群不一样，这两个客户群的网络行为不应用，他们之间的TPS
和PV关系比例也不一样。
6、淘宝
A)淘宝的TPS和PV之间关系通常为，最高TPS:PV大约为 1:113600（相当于按最高的TPS访问11个小时，这个是商品详情的场景，不同的应用场景会有一些不同）B2B中文站
B)B2B的TPS和PV之间的关系不同的系统不同的应用场景比例变化比较大，粗略估计在1:8个小时左右的关系（09年对offerdateil的流量分析数据）。旺铺和offerdetail这两个比例相差很大，
可能是因为爬虫占得比例比较高的原因导致的。
在淘宝环境下，假设我们压力测试出的TPS为100，那么这个系统的日吞吐量=10011*3600=396万
这个是在简单（单一url）的情况下，有些页面，一个页面有多个request，系统的实际吞吐量还要小。
TPS（Transaction per Second）与其他性能指标的关系：
TPS和并发虚拟用户数（U_concurrent)、Loadrunner读取的交易响应时间（T_response）之间有以下关系（稳定运行情况下）：TPS=U_concurrent / (T_response+T_think)。
TPS（Transaction per Second）总结：
1、利用并发用户数、期望响应时间，可以计算出TPS。
2、TPS只是用来计算的是期望值，性能测试过程中的TPS无法单独作为性能指标。
3、TPS数据方位理论值赢在10-100之间，低于10和高于100都说明系统存在瓶颈点。
4、利用TPS与平均事物响应时间进行对比，可以分析事物数码对执行时间的影响。例：当压力加大，点击率/tps曲线如果变化缓慢或者有平坦趋势，很有可能是服务器开始出现瓶颈。
5、TPS是从客户端角度审视服务器处理能力，不能证明TPS可以达到什么程度就能支持多少并发，两者没有必然联系。
6、TPS会受到负载的影响，也会随着负载的增加而逐渐增加，当系统进入繁忙期后，TPS会有所下降。
七、添加监听器（Hits per Second）（每秒点击数/点击率）
jp@gc - Hits per Second：每秒点击量，点击量在性能测试-常见的性能指标，指的是每秒web服务器接收到的请求数
八、添加监听器（Response Codes per Second）（测试时间和响应代码关系图）
该侦听器显示在测试长度内每秒所有样本的响应代码速率。在系统经常以错误代码响应或需要区分不同的响应代码的情况下，此图非常有用。
九、添加监听器（Bytes Throughput Over Time）（吞吐量-随着时间推移）
在压力测试期间接收和发送的bytes数。
十、添加监听器（Transaction Throughput vs Threads）（吞吐量-随着用户数推移）
每个活动线程数的事务吞吐量，X轴表示的是活动线程数，Y轴表示的是事务吞吐量，F（X,Y）的含义是当系统处于某个活动线程数时，系统当时的事务吞吐量是多少，比如当有10个活动线程时，事务吞吐量是100/s，而当有20个活动线程时，事务吞吐量是50/s，说明随着用户访## 标题问的增加，系统的处理效率开始下降了，从这个图中可以找到一个临界点，在多大的活动线程数时，系统达到最大的吞吐量。
