Where rubber hits road

In the first part of this four-part Industry Insight, I spoke about the evolution of application performance management (APM) and business service management (BSM).

Companies are starting to see the value of supplementing inside-out with outside-in performance monitoring.

Jaco Greyling is solution strategist at CA Southern Africa.

Now I will address the first part of APM, called 'end-user experience (EUE) monitoring'.

There are a couple of reasons why EUE monitoring is critical for today's CIO. Firstly it's where the rubber hits the road - the first step in monitoring overall application performance. Customers are the lifeline of any business and it's ultimately all about their experiences. If they perceive a service to be poor, they'll undoubtedly take their business elsewhere.

In today's consumer-driven culture, customer psychology is all about the user experience, which includes: branding, usability, functionality and content. A bad user experience can mean the difference between success and failure.

Today's complex and heterogeneous environments make it virtually impossible to monitor business applications from a single construct. The modularisation of applications, combined with redundancy and dynamic architectures - like dependency injection - makes monitoring applications inherently difficult.

The three main mechanisms for monitoring EUE include: synthetic transaction monitoring; packet capture and HTTP-based analyses; and endpoint instrumentation.

Synthetic transaction monitoring is one of the oldest and most widely used monitoring techniques. This involves monitoring the application from certain locations - also called point of presence - using software robots to simulate real end-user transactions. In recent years, this method has given way to newer techniques, including real user transaction monitoring.

Recently, this form of monitoring has been revived due to its ability to monitor applications during 'off-peak' hours. This allows businesses to predict or pre-empt any potential performance problems before their market comes online - also called proactive monitoring.

Another reason for this and one that is increasingly more popular - is the software as a service (SaaS) delivery model. With more customers moving to cloud computing, companies are starting to see the value of supplementing inside-out with outside-in performance monitoring. This has become especially important for some managed service providers (MSPs), creating a competitive advantage through APMaaS.

The next mechanism for EUE monitoring includes packet capture and HTTP-based analysis - currently the most popular due to its real-time monitoring nature. The problem with synthetic transaction monitoring is systemic if the actual performance of end-users can't be monitored. If a user phones complaining about slow response time, can it be proved or disproved? This is where real user transaction monitoring comes into play. This is also known as an inside-out monitoring technique. It is achieved by placing a network appliance in the data centre next to a network tap - a hardware device which provides a way to access the data flowing across a computer network.

HTTP-based analysis facilitates: scrutiny of business transactions; analysis of end-to-end response time; quality of response; and reporting on error conditions like missing responses. With TCP as the delivery mechanism, overall response times can be measured from the point of the incoming request to the point of delivery to a client - also called the roundtrip time.

What about non-HTTP-based application architectures like Citrix or SAP? While some niche vendors provide protocol coverage for vendors like Citrix's ICA protocol, they're often not informative about the end-user experience or are coded and must be reverse-engineered. A better approach is to use TCP session monitoring instead.

Most thick-client architectures associated with off-the-shelf packages use TCP/IP as their transport and control protocol. Packet capturing devices allow users to assign a specific (destination) port to a specific class of application - it associates performance with the application class.

The last form of EUE monitoring is endpoint instrumentation. This is the original form of thick-client application monitoring and requires users to install an agent on the client's device (eg, desktop PC), monitoring the EUE first hand from the originating source. This might seem the ideal solution to the problem of true end-user monitoring, but the problem is scale. If there are 1 000 users, the solution needs to be deployed to 1 000 devices - not always feasible, especially if the recipient is off-site.

In 2008, Steve Souder of Google published: 'Episodes: a Framework for measuring Web page load times'. In this approach, he talks about injecting monitoring functionality into Web pages. As the Web page is rendered, the monitoring capability 'wakes up' and starts collecting user performance data, including rendering times.

What makes this different from the packet capture approach? The fundamental shift is from the network to the browser, where more and more Web 2.0 applications are shifting computational processing from the server to the client-side. This form of monitoring is very useful in mobile delivery systems, since it doesn't require any agents to be installed. It's becoming increasingly important to measure the rendering times in addition to the delivery times. These mechanisms are equally important in the delivery of a mature APM solution.

In my next Industry Insight, I will shift focus from the end-user to the application runtime architecture discovery and user-defined transaction profiling.