【问题标题】:Tomcat unexpected maximum response time for a request when load testing is done using jmeter使用 jmeter 完成负载测试时,Tomcat 对请求的意外最大响应时间
【发布时间】:2020-05-05 04:33:19
【问题描述】:

我有一个 spring boot 应用程序,它有一个 post 端点,它接受请求并将其发送到另一个服务并获取响应并将其保存到 mongo 数据库并将响应返回给用户。应用部署在spring boot的嵌入式tomcat上。我正在使用 jmeter 查看最大响应时间、吞吐量等。

当我从 jmeter 运行 500 个线程的测试 10 分钟时,我得到的最大时间约为 3500 毫秒。 当我从 jmeter 重复测试时,最大时间减少到 900 毫秒。 同样,如果我在很长一段时间后运行测试,最大值再次上升到 3500 毫秒。

我无法获得有关 tomcat 的这种行为的任何信息。

你能帮我理解一下tomcat的这种行为吗?

【问题讨论】:

  • 我猜和tomcat无关。这是您的应用程序代码。检查应用程序日志并找出哪个操作需要时间以及为什么?

标签: spring-boot jmeter embedded-tomcat


【解决方案1】:

“意外”是什么意思?重复测试时响应时间较短可以通过您的应用程序实现来解释,例如当您开始对刚刚部署的应用程序进行负载测试时,它的性能可能不是最佳的,当您重复测试时 cache is "warmed up" 所以你获得更好的性能。

另一种解释可能是JIT optimization,因为 JVM 正在分析您的应用程序使用模式,并对字节码进行内部改进以更好地服务于给定的负载模式。

第三种可能的解释是MongoDB caching,如果 500 个用户发送相同的响应,则可能是数据库将结果集存储在内存中,当您重复测试时,它实际上并没有访问存储,而是返回结果直接从内存中获取,既快速又便宜。正确考虑parameterizing your JMeter test,因此每个线程(虚拟用户)都将使用自己的凭据并执行与其他线程不同的查询,但请记住,测试需要是repeatable,因此不要每个都使用唯一数据时间,最好有足够的预定义测试数据集

【讨论】:

    猜你喜欢
    • 2014-04-13
    • 1970-01-01
    • 1970-01-01
    • 2018-01-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2019-11-15
    • 1970-01-01
    相关资源
    最近更新 更多