Reputation: 262
I have an action which fills in a form with 2 fields and clicks submit button.
Issue: load time for this sampler grew up during several script runs from 2-3 sec initially (which was visually close to manual execution) to 14-16 sec with no visible reason (no changes in application or script).
Investigation: ~4-5sec pauses between click into a field and sendKeys actions for both 2 fields in script when manually fields are clickable with no visible delays after form appears.
Q: Is there any explanation of such strange behavior with ~5sec + ~5sec pauses in each field?
What should I do to fix this issue with too long and unexplainable pauses which provide unrelevant results?
Should I consider to switch to JSR223/groovy or it is not sampler type & code-related problem?
Upvotes: 0
Views: 41
Reputation: 167992
Your question doesn't tell the full story so I don't think it's possible to come up with the comprehensive answer so far only few generic recommendations:
Take a thread dump at the moment when JMeter is "waiting" and doing nothing, it will allow you to detect what's going on there
Monitor JVM parameters using JVisualVM or equivalent, it might be the case the JVM is doing garbage collections to free up heap memory space, in this case you will have to tune JMeter for maximum performance
You're "finding" the element twice, the second line is absolutely unnecessary so instead of
wait.until(pkg.ExpectedConditions.visibilityOfElementLocated(pkg.By.xpath("some xpath")))
var element = WDS.browser.findElement(pkg.By.xpath("the same xpath"))
you can do it only once like:
var element = wait.until(pkg.ExpectedConditions.visibilityOfElementLocated(pkg.By.xpath("some xpath")))
XPath is the most powerful but the least performing locator strategy, if it's possible - try to stick to element ID attributes, if it is not possible - go for CSS Selectors
Follow JMeter Best Practices like don't run your test in GUI mode, avoid storing response data, etc.
Upvotes: 1