Release :
Component : PACKAGE CA BLAZEMETER
There hasn't been any reports of BlazeMeter outages.
We've reviewed the logs from the test URL you provided, and noticed that in the Taurus script you are using is executing Gatling. However, when looking through the artifacts for the test, we also see a JMeter log created, meaning JMeter is also getting sun up, which Engineering said that should not be happening if you are executing Gatling. The issue is most likely an error in your configuration.
Below is the Gatling error I see in the bzt.log file:
[2020-04-24 20:57:21,919 ERROR root] Child Process Error: Gatling tool exited with non-zero code: 2
[2020-04-24 20:57:21,919 ERROR root] Gatling STDOUT:
GATLING_HOME is set to /shared/.bzt/gatling-taurus/2.3.0
20:56:53.505 [WARN ] i.g.c.ZincCompiler$ - Pruning sources from previous analysis, due to incompatible CompileSetup.
20:56:59.473 [ERROR] i.g.c.c.GatlingConfiguration$ - Your gatling.conf file is outdated, some properties have been renamed or removed.
Please update (check gatling.conf in Gatling bundle, or gatling-defaults.conf in gatling-core jar).
Enabled obsolete properties:
'gatling.http.ahc.allowPoolingSslConnections' was removed, dropped.
'gatling.http.ahc.allowPoolingConnections' was renamed into gatling.http.ahc.keepAlive.
Simulation com.ncr.nr1.order.performance.simulation.OrderServiceSimulation started...
20:57:03.421 [WARN ] i.g.h.a.ResponseProcessor - Request 'Create test organization' failed: status.find.in(200,409), but actually found 500
...
Also looking at your config-blazemeter.yaml, the way you're executing Gatling doesn't seem to be correct. We're not Gatling experts, but the execution doesn't look like the normal execution we see. Your script starts with:
settings:
default-executor: gatling
What we would expect to see is something like: (see https://gettaurus.org/docs/Gatling/)
execution:
- executor: gatling
scenario: sample
We suggest going back and taking another look at your configuration yaml, and why Gatling is not getting executed properly.
Engineering also confirmed that anytime you see a status code 500 (Internal Server Error), it is always reported by the end point you are attempting to test, and not due to BlazeMeter. In most cases it related to the gateway unable to reach the end point application.
I hope this was helpful, and gives you a starting point to troubleshooting your test configuration.