建议阅读官方操作手册 解释得还算清楚

你说的是这段吗？我是在这个地址下看到的，不知道是不是你说的手册，但是这里看完以后，也没看明白。

参阅 18.9

谢谢，刚刚仔细研读了一下，有收获。

请教一下，怎么能够通过线程组来来推算出并发数呢？

实际测试过程中线程组与并发数的关系不大，只是限制了可能的最大并发数（就像你安排 10 个人去做一件事，同时做事的最多不超过 10 个）
执行测试时并发数是受到性能瓶颈限制的（比如业务中限制每次只能一个人做事，其他人只能排队）
一种不怎么精确的计算并行线程数的方式 TPS* 平均响应时间

好的，谢谢

用户数 != TPS * 响应时间，这个公式完全不成立。

你可能有什么误解 我说的是不精确的 并行线程数 不是用户数
另外指正问题的时候，方便阐述下你的观点吗

我的观点是，这个公式容易误导人，不提更好。
严格意义上的并发用户数：指与系统建立连接，并对系统发起请求，对系统造成压力的用户；注意：并发用户数不能完全代表对系统的压力，比如 100 并发用户与系统建立了连接，每秒发一次请求，每 10 秒发一次请求，这两种行为对系统的压力是完全不一样的。
可以通过查询 被测服务器有多少来源于压力机的 IP 与服务器建立了连接，来计算真实并发。

一般情况下，性能测试是将系统处理能力容量测出来，而不是测试并发用户数。
JMeter 的线程只是用来产生并发请求的技术手段。

这个处理容量用什么指标衡量呢？我们目前的任务就是让测试一个服务的并发数，所以我才觉得要得出并发数才对。

服务器端一般用 RPS（每秒请求数) 这是从服务器角度来说的；tps 实际上包括了请求到达服务器以及从服务器返回客户端的响应所有时间加在一起的;

我刚才可能描述的不准确，我们测试的是一个二次封装的 Nginx 的并发数。按你说的来理解的话，应该是 tps 更符合要求，不知道这样理解对吗。
然后就是，因为有了多大的并发，才会产生怎样的 tps,所以并发还是一个很关键的指标。不知道这样理解对不对。

实际测试过程中严格意义的并发数似乎本身就没有落地到实处的意义，而且针对客户端与服务端并发数的意义也不同
了解到实时与服务端交互的大约进程数不更有利于分析测试结果吗

你这完全就是把并发数和服务端每秒处理能力搞混的人

从始至终我的观点里，都没有说过并发数，不知是怎么判断我把并发数与 TPS 搞混的呢？

有疑惑的可以看一下我的博客https://testerhome.com/topics/21318

如果你说的并发数指的是并发用户数，那么线程数就是并发用户数
如果你说的并发数是并发请求，那么它叫 rps，rps=（线程数 * 线程迭代次数）/s，称之为每秒并发请求数
不论并发用户数还是并发请求数，代表的都是压力值。压力测试通过设计压力值来测试服务器，获取 TPS 值，衡量服务端性能。
想加压力，要么加人，要么加单位请求。人做不到的只有机器来做

感谢回答。但是关于计算 rps 这里，如果勾选 infinite，那线程迭代次数怎么办呢？

勾选永远，线程会以最大迭代次数去运行。最大迭代次数由请求的响应时间决定。响应时间如果是 10ms，那 1s 就可以迭代 100 次

明白了，感谢。
另外想请问一下，非 GUI 分布式压测的时候，除了查询 pid 去停止 slave 的工作，有没有什么命令可以使用呢？