JM TPS

Transaction Rates and Build Pass/Fail

Something else that would be great for Jenkins CI builds is to check the transactions per second rates. A build may fail if the pass rates are not high enough or if the fail rates are too high.

To do this, I have used the same assertion files as for the assertion checking

Code snippet:

rate1

After the test run you can then call rate-check.sh to report results back to screen:

rate2

And the output is presented in the log to three decimal places. One problem here is that jtl files (with the jmeter/jenkins plugin) only accept integer values. So the values need adjusting for graphical display. This may be an issue for low transaction rates but the pass / fail criteria is based on the decimal values so that at least is more accurate:

rate5

Also, again, the jmeter plugin graphs are not very configurable so the title says responding time. This will just have to be explained to your users. The left graph shows the rate to the nearest integer and the right graph shows the pass fail status (0 or 100 Iím afraid instead of pass fail. 0% errors = pass, 100% errors = fail):

rate4

[Home] [About (CV)] [Contact Us] [JMeter Cloud] [JM Highlights] [JM Overview] [JM Control] [JM Inject] [JM Threads] [JM Results] [JM Assertions] [JM TPS] [JM Metrics] [JM Runtime] [JM Collation] [JM Logs] [JM 95th] [JM 95th v2] [JM Jenkins] [JM Corporate] [JM Scripts] [JM Variables] [JM Embedded] [JM Hosts] [JM Running] [JM Example] [JM Versions] [webPageTest] [_64 images] [asset moniitor] [Linux Monitor] [Splunk ETL] [Splunk API] [AWS bash] [LR Rules OK] [LR Slave] [LR CI Graphs] [LoadRunner CI] [LR CI Variables] [LR Bamboo] [LR Methods] [LR CI BASH] [Bash methods] [Jenkins V2] [Streaming vid] [How fast] [Finding Issues] [Reporting] [Hand over] [VB Scripts] [JMeter tips] [JMeter RAW] [Dynatrace] [Documents] [FAQ] [Legal]

In the Cartesian Elements Ltd group of companies