你起线程的时候，你去看服务器上啊 真的能打这么高吗

压力机看打印的日志，开始时间到结束时间大概是 40s 左右。

直接看你的被测服务是不是真的接了符合预期的请求量，先排除这么乱来的线程数是不是真的能发；确认了是有，再来考虑这里的问题

我从被测试服务线程数看，并不是预期的 jmeter 集合点并发请求的值。

还有个问题，jmeter 创建 10000 个线程，应该不是并发请求的吧。是循环发送请求的吗？

线程太多，大量的 CPU 时间都用在了线程切换上，实际并发数量并不等于线程数量

那是不是可以理解为设置这个线程数过大了，实际上系统发不了这么多线程数。回到帖子的问题，是不是已经解决了？

【jmeter 创建 10000 个线程，应该不是并发请求的吧。是循环发送请求的吗？】最好把配置截图发上来看看，我用 jmeter 很少，可能是我自己混淆了一些概念。

是的。从被测机器上看实际并不是并发 10000。那实际并发数量什么情况下等于线程数量呢？

是被测试的机器吗？

通常并发是指 1 秒钟之内发出的请求数，单线程也可以并发上千上万，跟线程数量没有必然关系。因为 jmeter 用线程模拟用户，线程在 cpu 上的切换也需要消耗时间，剩下的才是实际执行逻辑运算的时间，线程越多切换时间就越多，实际执行逻辑运算的时间就越少，真正能并发多少个线程不是固定的，受线程中 IO 阻塞时间而定，而 IO 又是十分耗时且不稳定的，所以 jmeter 很难计算一个最具有效率的线程数量。压测过程实际并发数只能通过执行过程中进行统计

明白。在实际的并发测试过程中，不同的接口要在压力机找到能够支持多大的并发数，然后通过分布式的方式达到高并发的模拟吗？

对的，就 jmeter 而言，多做几次你就发现会有一个单机效率最高的线程数量配置区间，也就是网友总结出来的大概 1000 到 3000 个线程，具体跟 CPU 性能相关，以此为基础进行分布式扩展

好的。明白了，多谢大佬。

1w 并发，指的是 jmeter 会创建 1w 个线程 (keeplive) 并循环 发送请求到目标服务器，集合点则是 当空闲线程数达到了配置阈值，则开始发送请求。
压测过程，需要看实际情况，以及目标服务器的处理能力，追求并发数据意义不是很大 (除非是长链接)。应更多关注服务端的 QPS/TPS。将并发数作为加大压力的理解会更好点。
另外，不断增加并发数，会加大施压端的资源消耗，如内存，CPU，IO，网络带宽等到达瓶颈，应视实际情况来调整并发。

使用多台压测机

单机撑不了这么高的并发，需要分布式，每台 最优是 1000 到 3000

目前看是的，这个最优是怎么评估出来呢？

真实场景压测来的，是真实数据，而且压力机硬件配置 都差不多高配了

真实场景，其它还是要看压测接口，不同的场景，并发数会有差异的吧。

可以解决问题，但是一般前期需要评估资源的

了解。集合点也不是并发请求的吧。我们内部会有一些线程池和队列的测试。例如配置 threads=1000，100 并发，tps=1000 并不会出触发线程池异常。反而 1000 并发，会触发线程池异常。

最好的方式看官方文档

嗯，我其实就是想验证下，机器支持的并发数已经到上限了，会有什么表现。或者怎么验证已经到上限了。

表现就是比如你机器只能支持不到 2000 线程，当你起到 1900 的时候，线程数就很难上去然后卡死了

关于是否并发问题，可以添加一个同步定时器，可以对比一下并发的效果；
对于线程数是否能达到 10000，不一定能达到问题，不说 cup 有很多影响，带宽和连接池都有影响；感觉就算测试一万并发也不是用这种方式去测