我正在使用JMS场景运行Gatling 2.3.0。当运行这个场景8小时我收到不同的结果,我。即提交的邮件数量不同(大约数百条邮件与数千封邮件的数量相比)。
使这更具体:
messages being submitted through Gatling WITHOUT file reading: 7.976.342
messages being submitted through Gatling WITH reading from file: 102.336
该方案每次都成功完成,每次持续约8小时。
与前一个场景相比,唯一发生了变化的事情(即提交数百万条消息的场景)是另一条消息的整合。
我正在使用文件阅读器检索邮件的内容。在负载测试期间,该服务(负责转发JMS消息的路由服务)已启动并正在运行。
作为一个非常大的字符串消息,我正在使用文件阅读器,而不是将字符串值作为模拟文件中的变量:
val pdubloadmessage =
scala.io.Source.fromFile("pdubload.txt").mkString
场景定义如下:
val scnpdubloadMessage = scenario("Load testing GPRS InboundQueue on MQ-HOST-1 with PDUpload-Message").during(8 hours) {
exec(jms("F&F testing with MessageID PDUpload").send
.queue("FLEETBOARD.GPRS_MESSAGES.QUEUE")
.textMessage(pdubloadmessage)
)
}
最后注射:
// configuration for MQ-HOST-1
setUp,
scnpdubloadMessage.inject(rampUsers(40) over (1 seconds)).protocols(jmsConfigMQ1),
// remaining lines for other scenarios omitted
有没有人知道这个问题的根本原因?我怀疑文件处理是问题所在。