I ended my previous blog post with the question: “Why is the consumer application not fast enough?“
This is a very common question. The root cause of slowness or increased response time is often not very obvious.
For the end user the system she/he interacts is slow. Reality though is that this is not always true.
Let me take you through an example and show what we can do to find the real root cause.
Thread dumps and logs are a starting point if the issue is not intermittent (and it is Java).
Simple take a series of thread dumps using “jstack -l <pid>” and pass this to the support team of the product in question.
For intermittent issues and/or heterogeneous environments (e.g. .net + Java) the root cause analysis is more complex.
The issue can be load, data(size/content) or environment related. The more backend systems involved in one request the more complex it becomes.
For this blog post I created an example to illustrate this.
A customer tries to access a web app and is experiencing long wait times after triggering a request.
The app is a ASP.net page which interacts with a REST API. The REST API itself is sending requests to a JMS queue.
From that queue an integration engine (CX Messenger, Sonic ESB) is picking up the message.
A business process flow is executed and then the response is sent back.
As you can see there are several systems involved. You might argue now that this is a constructed example.
I agree but reality is often even way more complex than this.
Which makes it often quite hard to understand all the reasons why the final response time is so high.
Back to the example. The customer experience happens at the web page, no matter what is done behind the scenes.
The user reported a wait time of circa ten seconds till the page is loaded. Network issues as potential cause have already been eliminated by the operations teams.
Normally the investigation would now start with logs of all involved components and teams.
Different technology-stacks, different ops teams, potential collaboration issues, time consuming… etc.
This is where CX Monitor (Actional) can show one if its strengths.
It allows you to dig into past traffic/interactions using a date time picker or you work proactively (preferred) using policies.
A policy defines a certain rule/condition/target. If the condition is met (e.g response time > 3s) then an action can be triggered.
Typically this action is an alert inside CX Monitor (can be passed to other monitoring systems/dashboards) but can be anything you want.
Part of the alert is information about the interactions and (if requested) the data involved in the complete interaction flow.
The flow itself can be reviewed and drilled into. It shows the interactions between the systems and APIs.
Example Flow Map:
For “slowness” root cause analysis I personally prefer a different view of the same data. The sequence table which is also part of the alert details in CX Monitor.
In our example it clearly shows us where the time is spent.
Example Sequence Table:
The ten seconds reported by the customer are confirmed by this. The sequence map shows that the time is spent in these components:
- 4 seconds in the aspx page before the REST call is made
- 2 seconds on the ESB business process on log file write
- 3 seconds on a JDBC/SQL call done by the app that is exposing the REST API
- 1 second again on this REST API app after the database call
Having this information promptly at hand can save a lot of time and gives valuable insights into monitored systems.
Monitoring can be done for a single application (e.g. Aurea CRM connector/interface/webservices) or a complete heterogeneous environment. Seamless view of interactions across technology stacks (.net, java, etc).
You can even add monitoring capabilities to your custom solution app.
You have access to all this via Aurea Unlimited which means no extra cost for your company.