Previous Topic: Changing Reporting DatabasesNext Topic: Recorders and Test Generators


Troubleshooting Reporting Performance

If you run load tests and find that the bottleneck in the test cases is writing the events to the reporting database, consider removing everything except metrics from the report generator.

Typically the issue is that DevTest trying to record too much data when doing a load test. On the Reports tab of the Test Suite editor, try turning off events in this order:

Properties Set / Referenced

This event generates the most number of rows in the database and is almost never useful for a load test. Keep in mind that there can easily be 10 or more property gets and sets for every step executed. In a load test, this adds up quickly to millions of rows in the database. For example, if you have a test case that is 5 steps (with 5 gets and 5 sets for each step) and you run 100 users for 10000 cycles, then you will have 50 million rows in the database.

Record All Events

This event is essentially a recording of the workflow engine. This can also easily generate 5 or more rows for every step. 

Request / Response

While this event does not create any extra rows, the payloads are stored as clobs because they may be large. This probably creates the largest amount of data but is easier on the database because the tables and indexes do not have to grow as rapidly.

If you still see the reporting engine as the bottleneck, consider enabling the lisa.reporting.useAsync=false property. This property tells DevTest to use JMS to send the reporting event. Background threads in the simulators and coordinator write the events to the database asynchronously. This means that your load test will finish before all the events are written to the database, so the report will not appear for some time. Just how long will depend on your test cases and how many events they generate. The simulator queue typically takes the longest to flush; you will get a message at INFO level in the simulator log showing the percentage complete.

The async reporting feature allows the simulator to run faster because it does not slow down writing to the database. It instead puts the data into a JMS queue to be written later.