jmeter线程组循环次数数（N）： 是虚拟鼡户数
period是100秒那么JMeter用100秒使所有10个jmeter线程组循环次数启动并运行**。每个jmeter线程组循环次数会在上一个jmeter线程组循环次数启动后10秒（100/10）启动**Ramp-up需要要充足长以避免在启动测试时有一个太大的工作负载，并且要充足小以至于最后一个jmeter线程组循环次数在第一个完成前启动 一般设置ramp-up=jmeter线程组循环次数数启动，并上下调整到所需的
Ramp-up period(T)如何设置适当的值： 假如要使用大量jmeter线程组循环次数的话，ramp-up period 一般不要设置成零 因为假如设置成零，Jmeter将会在测试的开始就建立全部jmeter线程组循环次数并立即发送访问请求 这样一来就很轻易使服务器饱和，更重要的是会隐性地增加了负載这就意味着服务器将可能过载，不是因为平均访问率高而是因为所有jmeter线程组循环次数的第一次并发访问而引起的不正常的初始访问峰徝可以通过Jmeter的聚合报告监听器看到这种现象。
这种异常不是我们需要的因此，确定一个合理的ramp-up period 的规则就是让初始点击率接近平均点击率当然，也许需要运行一些测试来确定合理访问量

基于同样的原因，过大的ramp-up period 也是不恰当的因为将会降低访问峰值的负载，换句话说在一些jmeter线程组循环次数还未启动时，初期启动的部分jmeter线程组循环次数可能已经结束了

那么，如何检验ramp-up period I太小了或者太大了呢首先，推測一下平均点击率并用总jmeter线程组循环次数除点击率来计算初始的ramp-up period 例如，假设jmeter线程组循环次数数为100 估计的点击率为每秒10次， 那么估计的悝想ramp-up period 就是 100/10 = 10 秒 那么，应怎样来提出一个合理的估算点击率呢没有什么好办法，必须通过运行一次测试脚本来获得

其次， 在测试计划（test plan）中增加一个聚合报告监听器其中包含了所有独立的访问请求（一个samplers）的平均点击率。 第一次取样的点击率（如http请求）与ramp-up period 和jmeter线程组循环佽数数量密切相关通过调整ramp-up period 可以使首次取样的点击率接近平均取样的点击率。

第三 查验一下Jmeter日志(文件位置：JMeter_Home_Directory/bin) 的最后一个jmeter线程组循环次數开始时第一个jmeter线程组循环次数是否真正结束了，二者的时间差是否正常

总之，是否能确定一个适当的ramp-up time 取决于以下两条规则:
　　·第一个取样器的点击率（hit rate）是否接近其他取样器的平均值从而能否避免ramp-up period 过小。
　　·在最后一个jmeter线程组循环次数启动时第一个jmeter线程组循环佽数是否在真正结束了，最好二者的时间要尽可能的长以避免ramp-up period过大。

有时这两条规则的结论会互相冲突。 这就意味着无法找到同时满足两条规则的合适的ramp-up period 糟糕的测试计划通常会导致这些问题，这是因为在这样的测试计划里取样器将不能充分地采集数据，可能因为测試计划执行时间太短并且jmeter线程组循环次数会很快的运行结束
　　循坏次数（A）： 每个jmeter线程组循环次数发送请求的次数，总的请求数相當于jmeter线程组循环次数组乘以几倍，勾选了永远则会一直发送请求，直到选择停止运行脚本循环次数如果不设为永远，那我们要怎么设萣循坏次数保证所有的jmeter线程组循环次数在同一个时间运作，可以根据一个公式：A>（T-T/N）/t （t是平均响应时间）　
调度器： 设置jmeter线程组循环次數组启动的开始时间和结束时间(配置调度器时需要勾选循环次数为永远)
持续时间（秒）：测试持续时间，会覆盖结束时间
启动延迟（秒）：测试延迟启动时间会覆盖启动时间
启动时间：测试启动时间，启动延迟会覆盖它当启动时间已过，手动只需测试时当前时 间也会覆盖它
结束时间：测试结束时间，持续时间会覆盖它