by Harper Mann

Tracking Application Performance Getting Trickier …

analysis
May 17, 20064 mins

At the recent Interop event, I was really amazed by how many exhibitors are hawking application performance solutions. Literally, you can’t walk more than 50 feet in any direction on the exhibit floor without seeing some booth personnel dressed like a pit crew member, waving a checkered flag and yelling into a megaphone about application speed, reliability, uptime, etc.

Now what’s interesting to me is the way that development trends these days are going to change the game with respect to how application performance is monitored and managed, and how infrequently I heard these new trends being discussed in these vendors’ pitches.

Consider a few of today’s hot application development trends, and how they are likely to impact that way that app performance is monitored in the future:

AJAX — Ann Bednarz at Network World had an interesting write-up yesterday where she canvassed a number of folks about the practical considerations for implementing AJAX. One of the points made near the end is that because of the predictive nature of AJAX and how it fetches extra data in anticipation of demand – AJAX apps tend to put extra drag on the network. AJAX is one of the really hot application development approaches today (especially for web applications), so we’re likely to hear more increasing discussion about the performance issues associated with deploying rich AJAX applications.

MASH-UPS — With XML and Web services, we’re seeing many more corporate developers today that are writing applications that call a bunch of applications on the back-end. The mash-up craze so far has been pretty consumer-focused, but it’s starting to creep into enterprise application development discussions as well. So the implication is that as more applications start to communicate with more databases and security systems, the sheer number of subcomponents that one must consider when evaluating application performance goes up considerably.

SOA — InfoWorld has given a ton of discussion to service-oriented architectures, and while there are a wide range of opinions about how wholeheartedly SOA is being deployed by customers today — there’s no question that monolithic apps are being replaced by services. As Nemertes analyst Andreas Antonopoulos pointed out at Interop, however, with the flexibility of SOAs also come some new management issues. If instead of one 4-tier web app for CRM or ERP you are now running a collection of 100,000+ web services that create a composite application — how do you manage these with the big, top-down management apps that so many customers use today?

While at Interop, I also enjoyed NetworkPhysics’ “It’s not the Network” t shirts — which point to the fact that whenever something goes wrong for the user, the poor network guy is typically the first one that gets blamed when the finger pointing begins. But with the explosion of subcomponents (and connections between these components) in the typical IT environment today, chances are that the fingerpointing is going to continue to get more and more complex as we move ahead.

The classic, network-centric approach to monitoring applications is to leverage sentries to look at packets going by on the network to determine a specific application’s latency and performance stats. This approach originated with RMON (remote network monitoring management information base) in RFC 1757 in the IETF, and it requires a good characterization of the architecture of your system, and understanding the relationship between the given application’s connections to servers, databases, authentication systems, provisioning systems, and any other touch points that have I/O and could potentially be a bottleneck.

Developers often also run “synthetic transactions,” where you drive the GUI through an associated user activity, and monitor the execution of the task and note any problems before the application goes live. My experience has been that roughly between 1/3 and 1/2 of enterprises run synthetic transactions for integration testing before deploying new applications. But typically they aren’t run too often once the app is in production, because they can affect network performance (and they’re often brittle, if you change one minor variable in your network, you can break the test).