Performance Anatomy of a Web 1.0 vs. Web 2.0 Applications
In Web 1.0 all Application Logic happened on the server. The generated web page was transferred via the network to the browser which simply rendered the content. Performance Management was focused on the following items: performance of application code that generated the returned content, generated size of content, caching strategy and network performance.
Problem Patterns in Web 2.0 Applications
The problem patterns in Web 2.0 Applications are similar to Web 1.0 Applications but they have a different impact on overall performance as the application infrastructure now includes the browser and relies more on the network connection for asynchronous message exchange. Let’s have a look at 3 problem areas and how they impact performance:
Interactive User Interface
A well-known problem from the server-side is components that are very “chatty”. Having components that exchange many messages for simple transactions lead to performance problems caused by the overhead of message serialization/deserialization and message transmission. The ability to send asynchronous messages from the browser to the server to request additional content or to update the server with status messages is a great thing. What needs to be considered is that these messages need to be serialized/deserialized on both sides (browser and server) and need to be transmitted over a rather slow network connection (slow compared to LAN connections).
For an example of how to analyze chatty components read the End-To-End Performance Analysis with dynaTrace AJAX and dynaTrace server editions paragraph.
Problematic 3rd Party Libraries
End-To-End Performance Analysis with dynaTrace AJAX and dynaTrace server editions
I have chosen Magnolia – an open source content management system – to demonstrate how to do End-To-End Performance Analysis starting from the Browser all the way back to the Database. I use the FREE dynaTrace AJAX Edition to analyze the browser activities in combination with dynaTrace Test Center Edition for server-side performance analysis.
Step 1: Setting up dynaTrace APM
I start by creating a System Profile for Magnolia including all standard Sensor Packs that dynaTrace provides for Java based Applications. This includes Java Servlets, JDBC, Java Web Services, Exceptions, JMS, EJBs, RMI, Hibernate, … and many more. Additionally to this out-of-the-box configuration I add my own custom sensors for the individual magnolia packages using the dynaTrace Sensor Assistant to come up with a good set of instrumentation. I inject the dynaTrace Agent into the Magnolia startup script and I am ready to go.
Step 2: Executing the Use Case to be analyzed with dynaTrace AJAX
The actual use case I tested was logging into the administrative console of Magnolia, clicking through the dynamic trees and changing configuration values. After I am done I close the browser – go back to dynaTrace AJAX Edition and start with the Summary View.
Step 3: Analyzing the Browser Activities
Step 4: Analyze Server Side Activity
Once dynaTrace APM runs on the server that is analyzed with dynaTrace AJAX Edition you can drill from a Network Request in the dynaTrace AJAX Edition to the Server-side PurePath that was captured by dynaTrace APM for that particular request. This can be done via the Context Menu in the PurePath tree as shown in the previous screenshot or via the Context Menu in the dynaTrace AJAX Edition Network View:
We can see that the PurePath took 1.874 seconds on the server. The next really interesting observation is that we had 1.4 seconds in wait time – meaning that the application had to wait on an object for 80% of the total execution time. The Hot Spots visualization shows us which methods contributed to the PurePath. Hovering the mouse over the big block shows us it is the doDeactivate method. Clicking on that block automatically brings us to the most problematic method in the PurePath:
Additionally to the method execution times we get additional context information like method arguments (e.g.: delete for the execute method) – all thrown exceptions including exception message and full stack trace, SQL statements and their bind values and full details on the servlet request:
Going back to the problematic method we identified. dynaTrace even allows us to lookup the source code of this method that spends 1.48 seconds in wait. If we have the source code available we can look up the code in Eclipse using the dynaTrace Eclipse Plugin. If you do not have the code available we can choose to see a decompiled version of this code:
This code-lookup feature works for both Java & .NET where dynaTrace also integrates with .NET Reflector to show disassembled code.
Conclusion: Why we need the End-To-End View
Modern Web Applications include the browser as part of the application platform. When it comes to performance management of those applications it is therefore necessary to start at the browser and go all the way back to the server and database. The more frameworks (server and browser-side) you add to the mix the more complex the application and the more critical it becomes to understand what is going on from end-to-end for every user interaction in order to understand and tune web site performance. In the end it is about giving your end-users the best possible experience on your website in order to keep them as users. The FREE dynaTrace AJAX Edition for browser performance analysis and the integration with dynaTrace APM offers full End-To-End tracing and enables performance management for the new challenges of Web 2.0 Applications.
As noted in the opening paragraph – check out our recent webinars with Zappos and Monster and see how they use the dynaTrace AJAX and dynaTrace APM Solution to manage Web Site Performance of their Web Sites.