【问题标题】:Jmeter Transactions Per Second do not represent actual requests processed in secondJmeter Transactions Per Second 不代表每秒处理的实际请求
【发布时间】:2021-09-26 12:18:02
【问题描述】:

我在这里很困惑,什么是正确的参数来查找我的服务可以在一秒钟内处理多少个请求。 例如:根据 docs & this post TPS(transactions/sec) 是根据请求的经过时间计算的,当您拥有一个服务实例时,这似乎是公平的。例如:我经过的时间是 1 秒,所以我的 tps 是 1,这是有道理的,但是当我有 3 个服务实例(H-Scaled)时计算失败,虽然经过的时间保持不变,但现在我可以处理 3 个并发请求相同第二个理想情况下应该读回 3 tps,但它没有

问:那么在 jmeter 报告中检查这个的正确参数是什么?还是我的理论错了?

【问题讨论】:

    标签: jmeter horizontal-scaling


    【解决方案1】:

    根据JMeter Glossary

    吞吐量按请求/时间单位计算。时间从第一个样本开始到最后一个样本结束计算。这包括样本之间的任何间隔,因为它应该代表服务器上的负载。 公式为:Throughput = (number of requests) / (total time).

    request是JMeter的Sampler产生的东西

    如果您正在进行一些可扩展性测试,您可以按如下方式对其进行测量:

    1. 使用 1 个服务实例运行 stress test,即从 1 个用户开始并逐渐增加负载,同时查看 TPS。在某些时候,您将达到由于某些bottleneck 而增加用户数量不会导致增加 TPS 的阶段。在遇到瓶颈之前测量用户数量和 TPS。
    2. 使用 3 个服务实例重新运行测试,您应该会看到瓶颈之前的用户数和 TPS 现在更高了。

    【讨论】:

    • 遗憾的是它不能那样工作,或者我无法以正确的方式模拟它,我有简单的节点服务、docker 文件、docker compose here github.com/LRagji/redis-lsm-timeseries/tree/H-scalling 调查结果:当我运行它时具有单实例和 1000 个用户的服务,它在这个数字资源瓶颈之外与 0.7k TPS 产生共鸣,但是当我以较低的用户访问相同的服务时,TPS 低于并且多个实例也无济于事
    • 我的意思是 700TPS= 资源限制,所以如果我运行 300 个用户,它应该会显示完整的 300TPS,但它不会因为公式中的时间部分起作用
    • 它应该“以这种方式工作”,如果不是 - “瓶颈”在其他地方,即您的系统在 CPU、RAM 等方面没有足够的资源,仔细检查 JMeter 和被测系统是否有足够的空间来使用 JMeter PerfMon Plugin 进行操作。由于潜在的race condition,在同一台机器上运行 JMeter 和被测系统也不是最好的主意
    • 它不是资源瓶颈,我可以保证导致它只是延迟响应并且机器也有足够的头部空间,我想我需要以更好的方式提出问题,但现在我可以接受你的作为答案...
    猜你喜欢
    • 1970-01-01
    • 2018-07-16
    • 1970-01-01
    • 1970-01-01
    • 2022-01-18
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多