Real Life Ajax Troubleshooting Guide
One of our clients occasionally runs into the following problem with their web app: They host their B2B web application in their East Coast Data Center with their clients accessing the app from all around the United States. Occasionally they have clients complaining about bad page load times or that certain features just don’t work on their browsers. When the problem can’t be reproduced in-house and all of the “usual suspects” (problem with internet connection, faulty proxy, user error, …) are ruled out they actually have to fly out an engineer to the client to analyze the problem on-site. That’s a lot of time and money spent to troubleshoot a problem.
Capturing data from the End User
In my recent engagement we had to deal with one of their clients on the west coast complaining that they can no longer login to the application. After entering username and password and clicking the login button, the progress indicator shown while validating the credentials actually never goes away. The login worked fine when trying it in-house. The login also worked for other user in the same geographical region using the same browser version. They run dynaTrace on their Application Servers that allowed us to analyze the requests that came from that specific user. No problems on the server side could be detected. So we ruled out all potential problems that we could identify from within the Data Center. Instead of flying somebody to the West Coast we decided to use a different approach. We asked the user on the West Coast to install the dynaTrace Browser Agent. The Browser Agent captures similar data as the dynaTrace Ajax Edition. The advantage of that agent is that it automatically ties into the backend. Requests by the browser that execute logic on the app server can be traced End-to-End, from the Browser all the way to the database.
The Timeline View as shown above gives us a good understanding on what is going on in the Browser when the user interacts with a page. Drilling into the details lets us see where time is spent, which methods are executed and where we might have a problem/exception:
Why the Progress Indicator didn’t stop
In order to figure out why the progress indicator didn’t stop spinning and therefore blocking the UI for this particular user we compared the data of the user that experienced the problem with the data from a user that had no problems. From a high-level we compared the Timeline Views.
Wrong XML Encoding caused Problem
As there was no proper error handling in place this problem never made it to the surface in form of an error message.
To troubleshoot problems it is important to have as much information at hand as possible. Deep Dive Diagnostics as we saw it in this use case is ideal as it makes it easy to spot the problem and therefore allows us to fix problems faster.
Want to know more about dynaTrace and how we support Web Performance Optimization from Dev to Prod? Then check out the following articles
- Best Practices on Web Performance Optimization
- dynaTrace in Continouous Integration – The Big Picture
- How to integrate dynaTrace with your Selenium Tests