是否需要调整jmeter给定的吞吐量，以找出系统的实际tps
例如：我正在为250个并发用户获得100 tps。运行了10个小时。我是否可以得出一个结论，例如我的软件每秒可以处理100个事务。否则我需要做一些调整并需要获得一个值。我之所以这样问，是因为当负载开始时，系统将花费一些时间来执行足够的工作（预热时间）。如果是这样，该如何做。请帮助我理解这一点。
答案 0 :(得分：0)
默认情况下，JMeter以最快的速度发送请求，影响TPS速率的主要因素是：
理想情况下，当增加线程数时，TPS数量应增加相同的倍数，即，如果您有250个用户并获得100 tps，则应该为500个用户获得200 tps。如果不是这种情况-这500个用户超出了saturation point，而您的应用程序bottleneck则介于250和500个用户之间（如果不是更早的话）。
关于“预热”时间-进行负载的推荐方法是gradually，这样您就可以让您的应用程序做好增加负载，预热缓存的准备，让{{3 }}编译器/优化器开始工作，等等。此外，通过这种方式，您可以将不断增加的负载与吞吐量的增加/减少，响应时间，错误数量等相关联，而同时释放250个用户不会告诉您完整的故事。参见
答案 1 :(得分：0)
系统预热时间因一个系统而异。预热期是配置被缓存的地方，不同的库被初始化（例如Builder.init（））以及其他初始函数，这些通常不会在后续调用中发生。如果您研究负载测试的结果，则一开始会有一段很慢的时间。对于大多数系统，它可能只有5到10分钟。如果测试时间长达10小时，则这些值甚至可以忽略不计。但是话又说回来，如果结果在开始时给出的值极低，则可以进行平均计算（它始终取决于从初始预热期到正常运行的跃迁）。
根据jmeter配置，此线程可以解释配置。 How to exclude warmup time from JMeter summary?