查看绩效测试行业常用的绩效指标
压力工具的线程数、用户数和TPS多人不知道压力工具的线程数和用户与TPS之间有什么关系。 同样，让我们先画一个形象来说明。
现在假设，上面的框中有四个箭头，每个箭头都表示同一个事务。 在说这张图之前，我先解释一下“同时性”这个概念是由什么数据支撑的。 上面的内容提到了很多指标，但是合并需要具体的指标。 我的合并是1000TPS，1000RPS，1000HPS，这个请随便定义。 但是，在一个具体的项目中，当dldfs同时说1000这个没有单位的词时，必须要能理解它是什么。 在上图中，实际上压力工具是4个并发线程，每个线程可以在1秒钟内完成4个事务，所以总的TPS为16。 这个很容易理解吧。 在大多数非技术人员的脑海中，这种场景的并发次数是4而不是16。 很难解释这一点，但我的做法是直接告诉别人合并是16，而不用在意4个线程。 这在我所有的项目上几乎都一样，一直没有误会。
户数、线程数、TPS的关系
那么如何定义用户数量呢？ 如果涉及用户的话会有点麻烦。 有人认为，由于用户具有业务意义，如果一个系统有1万个用户在线，就应该测试1万个并发线程，但这种逻辑是没有技术的。 通常对在线用户进行并发性分析。 在许多业务中，并发率低于5%或低于1%。 按5%计算，10000个用户x5%=500(TPS )。 请注意哦。 这里是TPS而不是并发线程数。 已经明确，如果这时的响应时间是100ms，则并发线程数量就是500TPS/(1000ms/100ms ) )并发线程(【每秒500个事务X0.1秒=0.1秒以内的用户数量】)。 通过这样简单的计算逻辑，可以看到用户数、线程数、TPS的关系
显然，如果此时的响应时间是100ms，则同时线程数为500TPS/(1000ms/100ms )=50 )。
解答：
对于事务而言，如果响应时间为100ms，这不是每秒1000ms/100ms=10tps的事务吗？
要达到500TPS，需要多少线程？ 500t PS/10 TPS=50http://www.Sina.com /
也可以理解为
500TPS*(100ms/1000ms )，100ms转换为0.1秒，500tps=每秒500事务数0.1秒=50事务
但是！ 响应时间不会一直是100ms吧。 因此，通常，上述比例不是一定的，而是随着同时线程数的增加呈趋势性关系。 所以，在简介中，我们强调了趋势这个词！
响应时间的258原则合理吗？ 关于响应时间，很多人表示258或2510响应时间是业界的通用标准。 然后他们问这个标准的出处在哪里？ 是谁写的？ 背景是什么？ 几乎没有人知道。 很难想象谁也不知道出处的原则，就像传言中说的那样，会扩散到那么大的范围。 出来后，就再也找不到源头了。 其实这是80年代的时候，英国的一家IT媒体就音乐缓冲服务进行的调查。 不安的裙子，2秒钟内得到顾客满意度好的结果； 5秒钟满意度下降，但有利润8秒钟利润就没有了。 于是他们公布了这个统计数据。 于是258 principle出现了。 翻译成中文后，它就像万年不变的定理一样，深深地影响着很多人。 从这个统计结果的出现，已经过去了将近40年，IT发展的可以上天了，这个时间现在完全行不通了。 所以，以后请不要出去，谈论258/2510响应时间原则之类的事情。 不专业。 那么，响应时间如何设计是合理的呢？ 这里推荐两种想法。 各行业比较数据。 找到使用系统的示例用户，进行统计并得出结果，是最有效的响应时间的标准。
:性能测试的概念概括为：性能指标、性能模型、性能场景、性能监测、性能实施、性能报告。 在性能场景中，基准场景、容量场景、稳定性场景、异常场景。 在性能指标中，TPS、RT。 (请记住，t的定义基于各自的目标。)