Improving Response Times for a 3rd-Party Online Quoting Application
As one of the largest providers of homeowners and personal liability insurance products in the United States, this Correlsense customer generates a significant amount of revenue from its online quoting system.
An online quoting application is a revenue generating application for any insurance company. For a while, users were experiencing average response times of between 20 and 30 seconds, sometimes even more. Understanding the application’s architecture and the cause of the performance problem was challenging, since the application was written by a third-party vendor and was customized by the company. This combination raised a lot of friction in the process of isolating the problem, where people from both the insurance company and the third-party vendor were involved. As this problem got C-level executive visibility, The CIO asked to deploy SharePath by Correlsense on this application in order to get to the bottom of the problem.
The application architecture was based on 6 different domains that consisted of 2 load balanced web servers, 2 load balanced application servers (PHP), and backend services including the rating and caching engines, 3 databases, and messaging. Each of these domains was a “suspect”, as well as the infrastructure and network.
Solution: SharePath Application Performance Management from Correlsense
Things are Not Always as They Seem
SharePath collectors were quickly deployed on all relevant application and infrastructure components.
Figure 1: SharePath’s topology map automatically detected all of the customer’s application components
Once installed, the IT Operations team began looking through the individual transaction’s sequence of events to find what was going on. The immediate conclusion was that the transaction was making hundreds of SQL calls every time it was invoked.
While this is indeed a problem that could be handled by the 3rd party vendor, the team wanted to get another perspective.
Disproving Assumptions, Focusing on Facts
Using SharePath application optimization and analytics views, they could see that in general, the amount of SQLs could range from 100 for a transaction that met the SLA to 700 for a transaction that did not. This sporadic behavior was assumed to be the result of application caching not functioning properly. In order to confirm or disprove this assumption, they dug deeper with SharePath’s datacenter intelligence tool. They were surprised to find out that when the application response time was at peak, the database was overly busy; however, the amount of activity within the database went down.
What it meant is that this was not a caching problem, but a locking problem on the database.
Figure 2: SharePath revealed that when the application’s response time is at peak (the blue line) the database level of activity is dropped.
Looking again at an individual transaction within this peak time frame the customer saw ‘update’ SQLs which took 6-7 seconds each. This reinforced the conclusion that the problem was within the database and not the application cache.
The operations team immediately sent a message over to the database administrator to review these issues whom in turn fixed it.
To find out more about how SharePath can help your organization, please don’t hesitate to contact us or alternatively just fill out the form below.