Welcome!

SOA & WOA Authors: Pat Romanski, Gary Kaiser, Elizabeth White, Patrick Carey, Greg Akers

Related Topics: SOA & WOA, Java, AJAX & REA, Web 2.0, Big Data Journal, SDN Journal

SOA & WOA: Article

Fixing Real Problems with Real User Monitoring

In production support it’s hard to correlate what may be happening on local servers with what users are reportedly experiencing

In production support it is often hard to correlate what might be happening on local servers with what users are reportedly experiencing. In April, the developers for a Java application that handles electronic distribution of scanned mail and electronic faxes were receiving reports that their application was running slowly from remote offices and came to our Performance Availability and Capacity Management (PaCMan) team for help in determining the cause of this issue. From vanilla server-side dynaTrace, everything was looking fine. No particular transaction was taking a substantial amount of time. This led us to believe that the problem may lie more on the client side. Coincidentally, we were in the middle of a Proof of Concept for dynaTrace User Experience Management (UEM) so we decided to apply these efforts towards this application to help identify the issue.

Getting insight into the actual click paths of end users and the load behavior of pages on certain browsers allowed us to improve Client Rendering Time by 47%, Overall Page Load Time by 29% as well as implementing a new feature in Struts that prevents users from impatiently clicking Save too many times causing problems on our server-side implementation.

Finding #1: JavaScript Load Behavior causing problems on IE7
After configuring UEM and collecting data for a couple of days the analysis began. The first thing to become readily apparent with UEM was that a large amount of time was being spent on the client side for rendering. This was done by putting the server-side contribution, network contribution, and estimated client time on the same graph. The application developers set on correcting this immediately. The client browser version was changed to IE 9.0 from IE 7.0, and several common Web performance optimization changes, such as changing the load behavior of JavaScript files, were made in order to reduce the render time. Figure 1 shows the amount of time spent in a typical work week on the client side before (dashed line) and after (solid line) these changes were implemented. This resulted in an average of 608ms (47.57%) reduction in client-side rendering time.

Figure 1: Changing JavaScript load behavior helped to improve client-side Rendering Time by 47%

Finding #2: "Impatient" trigger save action
UEM also gives you the ability to directly correlate user actions at the client with what happens on the server. Using this ability, we were able to identify that some users were exacerbating their slowdowns by repeatedly clicking buttons and hitting refresh while they were experiencing an issue. The developers plan to fix this issue by implementing an Apache Struts feature to allow only the first press of a button to cause an action. Figure 2 shows a user that was experiencing slowdowns due to network latency (viewable in UEM), but was increasing their slowdowns by repeatedly clicking the "Save to XXXX" button and the refresh button before the page had finished loading.

Figure 2: Getting insight into end users' actions reveled problems with users impatiently clicking Save several times

For findings 3 & 4, and for further insight, click here for the full article.

More Stories By Derek Abing

Derek Abing is a System Engineers with a leading insurance company focusing on application performance.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.