CI Tools and Best Practices in the Cloud

Continuous Integration

Subscribe to Continuous Integration: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Continuous Integration: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Continuous Integration Authors: Jason Bloomberg, Yeshim Deniz, Elizabeth White, Pat Romanski, Liz McMillan

Related Topics: RIA Developer's Journal, Java Developer Magazine


End-to-End Monitoring and Load Testing

New Integration from Keynote and dynaTrace

We’ve learned from recent studies that performance has a direct impact on end-user behavior and revenue. Load Testing is therefore critical to ensure that your application can withstand peak load during online rush hours. Continuous Monitoring of the live system enables a more proactive approach with problem identification.

Keynote is an expert when it comes to Mobile and Internet Performance. We at dynaTrace have been working with them to integrate their Load-Testing and 24/7 Monitoring Services with dynaTrace to not only know when applications are slow but to identify why and where they are slow. In this blog I will walk you through the scenario on how End-to-End Monitoring accelerates the testing phase and how to become more proactive when dealing with production problems. A follow up blog will cover Load Testing and how to speed up and reduce load testing cycles when combining Load Testing with Application Performance Management.

Introducing Keynote Monitoring
Keynote Monitors are unique in a way that they actually drive a real instance of Internet Explorer when executing a monitoring script. The script gets generated through KITE (Keynote Internet Testing Environment) which is a tool you download for free and which allows you to record your monitoring scripts. Once you are good with the recorded script it can be uploaded to Keynote and either executed as a one-time test or as a scheduled execution on a defined interval from different locations. The following shows a report of an on time test that got executed from multiple locations:

Keynote Instant Test Monitor Report

Keynote Instant Test Monitor Report

What is the reason for this slow web request?
What is interesting to see in the screenshot above is that the monitored page took much longer from Hong Kong than from any other location. The question now is: Is it a problem with the remote location (network latency, slow web connection, etc…) or is it a problem in the application that I monitored? To answer this question it is necessary to look into the application and analyze what happened for this particular request. That’s where the integration with dynaTrace becomes interesting as dynaTrace tells how long a single request really took on the server and where the time was spent, allowing fast root-cause analysis.

Keynote Monitoring Integration with dynaTrace
Every monitoring script that Keynote executes actually opens an instance of Internet Explorer and then executes the individual script steps in the browser. Keynote instructs IE to use a custom User-Agent String (this is the HTTP Header that identifies the browser to the web-server). The User-Agent string now includes additional information such as Keynote Transaction ID (every monitor has a unique ID), Keynote Agent ID (every Keynote Agent Location has a unique ID) and the timestamp indicating when the monitor was actually executed.

When dynaTrace manages performance on the application server it traces every single transaction (through its PurePath Technology) that gets processed by the application. These are transactions executed either by real users that browsed the web site or transactions executed by a Keynote Monitor. dynaTrace evaluates the User-Agent string for each transaction and can therefore differentiate between synthetic transactions and real end-user transactions. dynaTrace can also pull out the individual Keynote IDs (Agent, Transaction) and the Timestamp to get additional context about the origin of a request.

Monitoring an eCommerce Site
We installed dynaTrace on an eCommerce application and setup two Keynote Monitors to monitor two critical transactions for the eCommerce Site: Search and Last Minute Offers. These two monitors are executed every 15 minutes from different locations around the globe. The Keynote Dashboards immediately tell us if there is a problem from an end-user perspective:

Keynote indicates an availability problem and one spike in transaction response time

Keynote indicates an availability problem and one spike in transaction response time

The Keynote dashboard tells us that the Search (Blue) was unavailable at one point in time and that the Last Minute feature had one spike of response time from 5s on average to 9s. The questions now are: Was it the application or infrastructure that caused these problems? Is it problematic application code or a problem in the network (or content delivery)?

dynaTrace helps to answer these questions by analyzing all transactions that made it to the application server. The following screenshot shows a dynaTrace Dashboard showing transaction response times for these two Keynote Monitors. It also shows the transactional flow of these transactions through the eCommerce System:

Transaction Response Spike on Application Server in the Search Transaction

Transaction Response Spike on Application Server in the Search Transaction

The dashboard shows me that we had a huge spike at 8:35 AM with a transaction response time of over 75s on the Search Monitor. This explains the Availability Error in Keynote as the request takes too long. The Last Minute Monitor however looks OK meaning that the spike is not caused by an application problem but by a problem of delivering the content to the end user (Note -> need to check with our CDN and our web hosting company). The ADM (Application Dependency Mapping) on the bottom additionally helps me understand how these transactions flow through my system. All transactions come in through the web and are processed on up to 4 different Application Servers and access the database.

In addition to the response times I also put Slowest URLs and Most Contributing SQL statements on this dashboard. The monitor scripts execute multiple steps, so I am interested in which URL actually had a problem. As the application is very DB-intensive, I also want to know which SQL Statements are executed how often and what the DB Response Time is.

One URL with specific Search parameters caused this long running transactions

One URL with specific Search parameters caused these long-running transactions

The first good thing for me is that not only do I see the problematic URL, I also get the parameters that were passed to it. The next step is to take a closer look at the transactions that ran so slow. I drill into another Dashboard that highlights the problematic layers of my application, the problematic methods and the Hot Spot of the one particular transaction which brings me right to the root cause:

One URL with specific Search parameters caused this long running transactions

Detailed contextual information on this long-running transaction.

The problem is our list page that lists the search results. In this case it takes 78s and would probably go on even longer. Because the End-User (in this case Keynote) is actually closing the browser after a defined timeout, an exception is thrown that indicates a client side abort of the transaction.

The information we have on hand can be passed to the developer by simply exporting this PurePath into a dynaTrace Session file. We either attach it to a support ticket or just send it via email/Skype/IM to the developer who then imports it and looks at the same data that we just extracted from our production environment.

What is the real root cause of this problem?
The next question however is: what is really the difference between this slow-running search and other searches that seem to have executed much faster. The PurePath view not only shows me the slow transaction but all other faster search transactions as well. Selecting the slow along with a faster one allows me to do a direct PurePath-to-PurePath comparison highlighting what the exact differences between two logically identical transactions are:

Structurual and Timing Differences are automatically highlighted when comparing two transactions

Structural and Timing Differences are automatically highlighted when comparing two transactions

It turns out that the slow-running transaction was that slow due to a unique set of input query parameters. The search feature on the eCommerce site allows the user to refine the search with specific input parameters. As dynaTrace captures all parameters and the full trace, it is easy to spot what the difference in input parameters means to the actual transaction flow. The search query produced a very large list of results that were all rendered into HTML. Due to a very inefficient way of writing the generated HTML back to the Network stream, the request took long enough for end-user (in this case the Keynote Monitor) to close its connection and therefore abort the request.

Along with the diagnostic analysis features seen in the screenshots above, dynaTrace provides additional options to e.g.: focus on slow running Web Services, Remoting calls (RMI, WCF, JMS, …), Exceptions, Memory related performance problems, … All these analysis options are available when viewing live data on the dynaTrace Server (which collects the data) or when viewing offline data (e.g.: exported to a dynaTrace Session)

Benefit of Keynote to dynaTrace Monitoring Integration
End-User Monitoring is critical as you need to know when performance impacts your end-users around the globe. We learned from recent studies that there is a direct impact of performance on revenue. Keynote’s monitoring service allows you to identify problems for end-users around the globe. With the dynaTrace Integration it is easy to identify the root cause of such problems as every single monitor transaction can be followed through the application server all the way back to the database capturing contextual information along this transactional trace (PurePath) such as method arguments, SQL statements, exceptions, log messages, http parameters or session information. Fixing these problems when they are identified through synthetic transactions avoids waiting for real end users to run into those problems. Those users will most likely not tell you that they ran into a problem – they simply leave your site and spend their money with your competitor.

It is important to understand the performance characteristics of your application early on by conducting large scale load tests. Once deployed into production it is even more important to identify eventual problems early on. Not all problems can be found in testing so chances are high that there will be problems when you go live. In a fast-changing world with tight schedules and short release cycles you have to become more efficient with problem analysis and resolving these problems. Keynote provides the services to test and monitor your application; dynaTrace provides the performance management solution to become more efficient when it comes to identifying the root cause and fixing problems.

For more information also read the Top 10 Performance Problems from Zappos, Monster, Thomson and Co. It talks about the problems that can be avoided early and therefore not worry so much about your precious weekends once applications are shipped :-)

You might also be interested in how to tie Analytics Data to APM Data. Read my blogs on How to Automate Google Analytics and Combining Analytics with Performance Management Data.

Related reading:

  1. Integrated Cloud based Load Testing and Performance Management from Keynote and dynaTrace Load Testing has traditionally been done In-House with load-testing tools...
  2. VS2010 Load Testing for Distributed and Heterogeneous Applications powered by dynaTrace Visual Studio 2010 is almost here – Microsoft just released...
  3. Elevating Web- and Load-Testing with MicroFocus SilkPerformer Diagnostics powered by dynaTrace MicroFocus and dynaTrace recently announced “SilkPerformer Assurance” and with that...
  4. Week 2 – The many faces of end-user experience monitoring Inspired by a comment of Wim Leers on one of...
  5. Why we spend too much time with load testing I have been working with many clients that perform load testing...

More Stories By Andreas Grabner

Andreas Grabner has been helping companies improve their application performance for 15+ years. He is a regular contributor within Web Performance and DevOps communities and a prolific speaker at user groups and conferences around the world. Reach him at @grabnerandi