提问1
如何在大并发测试下，让登陆或者后续接口只执行一次？linux
回答
这个问题网上的答案其实不少，可是大多不靠谱。
好比推荐使用仅一次控制器，可是仅一次控制器对线程组无效；好比推荐跨线程组调用，可是这样比较繁琐，新人也搞不定；
其实只要各位对元件熟悉，这个问题很简单shell
下图100线程：
服务器
添加一个吞吐量定时器，选择总数计算微信
下面这就ok了，是否是很简单？cookie
提问2
大并发的登陆以后，后续接口在作并发的时候有一些session重复了，并发量越大，重复概率越高。如何保证后续并发的session不重复？session
回答
缘由实际上是由于jmeter的多线程存在竞争机制，那么并发量很大的时候，就会有一部分线程下的请求抢到了一样的session。
咱们能够把这些登陆口令在并发登陆的时候先在本地保存一份哦，用来代替用户名密码作登陆参数！多线程
好比下图所示的session并发
写个小脚本把这些session保存下来tcp
后续并发的时候直接引用这些cookie就好了函数
可是这种也有缺点，脚本会略微的影响吞吐量
提问3
如何识别tps拐点
回答
先分析下面这张图。下面这张图上展现了阶梯负载量，响应时间，tps三种数据
从图上能看出来三个趋势
1：tps升到一个相对高点以后，长期维持稳定，再也不升高
2：运行一段时间以后，响应时间开始逐渐升高，可是趋势不明显
3：随着负载愈来愈高，tps长期保持稳定
分析：
在负载逐渐升高的状况下，tps却长期不变。这并非说明性能很稳定，而是说明咱们单位时间内的单线程tps是在逐渐下降的（单位时间tps/总线程）。
再分析响应时间，咱们的响应时间其实也是在逐渐升高，从侧面反映出线程的tps是在降低的。
可是具体在多少负载量的时候咱们的瓶颈点已经到来？这张图上很差计算，咱们换一个监听器
这张图的趋势就比较明显了。随着负载升高，线程的tps逐渐达到一个高点，而后开始降低。那么这个最高点就是咱们的性能瓶颈点
提问4
jmeter作压测的时候，性能监听图形毛刺过多，看的想吐怎么办
回答
先秀一张图阶梯增压的图形，看看什么是毛刺
这个场景是阶梯增压，每5s加10个，加到200，而后持续运行
能够看出来tps曲线坑坑洼洼，高低不平，惨不忍睹，怎么给它打磨一下？
修改setting
再回头看一下图形是否是没那么多毛刺了？
可是tps曲线依然波动很剧烈，这是咱们的压力设置的不合理致使的
下面把ramp up值改为10s，让咱们的线程压力没那么大
响应时间的剧增老是伴随着tps的大跌
提问5
非GUI模式下作负载测试，修改参数好麻烦的说
回答
把关键参数都设置成变量，在非GUI下引用就好了，就像下面介样子
写一个shell脚本，参数所有引用一下
bat执行的时候就像下面这个样子，hin轻松有没有~
提问6
jmeter4444端口没法监听远程服务器怎么解决
回答
4444端口在阿里云和腾讯云服务上，是默认不开放的。想要监听到，有两种办法，一种是防火墙开放4444端口，一种是更换端口。命令以下./startAgent.sh --udp-port 0 --tcp-port 1234
提问7
远程机执行jmeter脚本，怎么快速更换csv参数路径？
只须要在参数路径中加入一组函数，就能够实现参数路径自动定位，以下
${__P(user.dir,)}${__P(file.separator,)}test.txt
这一组函数的做用是，不论在linux仍是在本机，均可以自动切换路径格式，不须要手动修改
Delay Thread creation until needed 是什么意思？
jmeter的线程组里面有一个Delay Thread creation until needed选项，以下图。
不少人不理解这个选项是什么意思，或者根据官方解释，认为它是延迟建立线程。可是延迟建立，在哪里体现出来你？彻底搞不清。
咱们能够经过jdk的监听器看一探究竟。
不勾选延迟建立
线程组设置1500线程，ramp up设置10s，不勾选延迟建立，循环次数设置为永远。以下图
运行脚本以后，咱们在活动线程监听器里面能够看到线程确实是10s内建立完成，以下图
可是咱们在jdk工具里面再看一下线程建立的过程，会发现线程几乎在1s内就所有启动完成了，以下图
勾选延迟建立
线程组设置1500线程，ramp up设置10s，勾选延迟建立，循环次数设置为永远。再次运行脚本，以下图
结论
经过对比能够发现，只有rump-up和delay-thread组合使用，才可让线程真正的实现延迟。jmeter上看到的延迟都是幻象。
本文分享自微信公众号 - 测试驿栈（uhz2008_2008）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。