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.