jmeter性能测试过程中遇到的问题及解决方法
问题1
如何在大并发测试下，让登录或者后续接口只执行一次？
分析
这个问题网上的答案其实很多，但是大多不靠谱。
比如推荐使用仅一次控制器，但是仅一次控制器对线程组无效；比如推荐跨线程组调用，但是这样比较繁琐，新人也搞不定；
其实只要各位对元件熟悉，这个问题很简单
下图100线程：
添加一个吞吐量定时器，选择总数计算
下面这就ok了，是不是很简单？
问题2
并发登录之后，后续接口在做并发的时候有一些cookie重复了，并发量越大，重复几率越高。如何保证后续并发的cookie不重复？
回答
原因其实是因为jmeter的多线程存在竞争机制，那么并发量很大的时候，就会有一部分线程下的请求抢到了同一个cookie
我们可以把这些cookie在并发登录之后本地保存一份，变成存量数据。
比如下图所示的cookie
写个小脚本把这些cookie保存下来
后续并发的时候直接引用这些cookie就行了
问题3
新人在jmeter压测过程中有哪些大的性能消耗？
分析
我们接着问题2做个拓展。压测过程中如果加入了数据的读写，会不会影响性能结果？
我们知道，读写本地文件是需要和磁盘做交互的。磁盘在系统中处于最底层，速度是最慢的。频繁的磁盘交互会极大的增加性能开销，影响测试结果。
所以问题2的解决方案是不可行的，会降低实际的tps。
解决方案
首先把cookie存到系统属性里面。存属性就相当于存到了应用缓存，缓存的查询效率是最高的。
{__setProperty(cookie,{__setProperty(cookie,{cookie},)}
后续请求处理cookie的时候，直接从属性表里面提取
${__P(cookie,)}
问题4
如何识别tps拐点
分析
先分析下面这张图。下面这张图上展示了阶梯负载量，响应时间，tps三种数据
从图上能看出来三个趋势
1：tps升到一个相对高点之后，长期维持稳定，不再升高
2：运行一段时间之后，响应时间开始逐渐升高，但是趋势不明显
3：随着负载越来越高，tps长期保持稳定
分析
在负载逐渐升高的情况下，tps却长期不变。这并不是说明性能很稳定，而是说明我们单位时间内的单线程tps是在逐渐降低的（单位时间tps/总线程）。
再分析响应时间，我们的响应时间其实也是在逐渐升高，从侧面反映出线程的tps是在下降的。
但是具体在多少负载量的时候我们的瓶颈点已经到来？这张图上不好计算，我们换一个监听器
这张图的趋势就比较明显了。随着负载升高，线程的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(user.dir,)}{__P(file.separator,)}test.txt`
这一组函数的作用是，不论在linux还是在本机，都可以自动切换路径格式，不需要手动修改
问题8
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上看到的延迟都是幻象。
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！
