Integrating Devaten with NeoLoad to transform your Load Testing Strategy

Integrating Devaten with NeoLoad to transform your Load Testing Strategy

In many cases, the software initially works according to the functional requirements and is green-lighted for delivery, but it may slow down over time and with new releases, due to database performance issues. Read this guide to find out how you can use devaten as a plugin in NeoLoad. So Neoload user can see devaten dashboard results in their tool. This is helpful as they can see the database bottlenecks during the load testing run.

By Mikko Larkela – Founder & CEO at Devaten

When measuring database performance is done as part of automation testing, I experience interesting and useful results. Here are the areas for running one of the test cases:

  • Number of SQL statements
  • Separately broken down by select, insert, delete, update quantities
  • Lock waiting time
  • Rollbacks
  • Database server CPU time and percentage
  • The number of rows read, the number of rows in the database during the test case.

Why is accuracy an asset?

The service change made for the new column is therefore very poorly implemented, there are iteration lists and several unnecessary SQL statements are executed to the database.

Problems are only beginning to arise in the process of producing, several batches notice slowness, and web services are also detected slowly.

This will start to find out where the fault and the time will easily pass for several days before the fault is found. In many cases, due to such a small change, a comprehensive performance test is not carried out, but problems only begin to arise in production. Enterprise application comprehensive performance monitoring usually requires a lot of calendar time and correcting the findings delays the entire delivery schedule.

Now that we are adding database monitoring as part of the application’s automation tests, we can immediately catch the number of SQL statements that have changed in different services. In this case, for example, the change to the general service affected many different use cases.

Another similar problem occurs when a developer changes a SQL statement that is in continuous use, for example by adding a new subquery to the query. In this case, select starts scanning the index several times. This type of problem cannot be found in even smaller test databases, as the database engine reads the entire table quickly. Slowness only begins to come when the application is tested in a production-like environment.

More than half of application performance bottlenecks originate in the database, but most application teams have little or no visibility into database performance.
“AppDynamics”.

More chances of success

When we add database monitoring as part of the application’s normal automation tests as well as performance tests, we immediately catch up with the number of rows read that have changed in different services compared to the situation before the change. In large enterprise projects,  database monitoring as part of performance monitoring significantly speeds up the correction of performance issues, and this way the entire project has a better chance of success.

What power does Devaten provide to Neoload?

Devaten is a leader in use case-based database performance monitoring and NeoLoad is a leader in load testing, but while putting the extra load on application NeoLoad don’t have the complete details about the database for the specific use-case and that is the important information devaten is providing to the Neoload so user can check the live details and act on it.

With these details devaten also provides the complete statistics to NeoLoad so users can check the complete status about the Spike reason along with events.

If you want to know more about Mikko’s presentation, the recording is already available here.

Related Post

Leave a Comment