This post is part of our series on the Top Application Performance Challenges.

Over the past couple of weeks we helped a few DevOps groups troubleshoot performance problems in their production Java-based applications. While the applications themselves bore little resemblance to one another, they all shared one common problem. They were full of runtime exceptions.

When I brought the exceptions to the attention of some of the teams I got a variety of different answers.

• “Oh yeah, we know all about that one, just some old debug info … I think”
• “Can you just tell the APM tool to just ignore that exception because it happens way too much”
• “I have no idea where that exception comes from, I think it’s the vendor/contractor/off shore team’s/someone else’s code”
• “Sometimes that exception indicates an error, sometimes we use it for flow control”

The response was the same – because the exception did not affect the functionality of (read: did not break) the application it was deemed unimportant. But what about performance?

In one high-volume production application (100’s of calls/second) we observed an NPE (Null Pointer Exception) rate of more than 1000 exceptions per minute (17,800/15 min). This particular NPE occurred in the exact same line of code and propagated some 20 calls up in the stack before a catch clause handled it. The pseudo code for the line read if the string equaled null and the length of the trimmed string was zero then do x otherwise just exit. When we read the line out loud the problem was immediately obvious – you cannot trim a null string. While the team agreed that they needed to fix the code, they remained skeptical that simply changing ‘=’ to ‘!’ would really improve performance.

Using basic simulations we estimate this error rate imposes a 3-4% slow down on basic response time at a minimum. You heard me, 3-4% slow down at a minimum.

And these response issues get compounded in multi-threaded application server environments. When multiple pooled threads slow down to cope with error handling then the application has fewer resources available to process new requests. At the JVM level the errors cause more IO, more objects created in the heap, more garbage collection. In a multi-threaded environment the error threatens more than response times, it threatens load capacity.

And if the application is distributed across multiple JVM’s … well you get the picture.

The web contains many articles and discussions on the performance impact of Java’s exception handling. The examples in these posts provide sufficient data to show that a real performance penalty exists for throwing and catching exceptions. Doing the fix really does improve the performance!

Runtime Exceptions happen. When they occur frequently, they do appreciably slow down your application. The slowness becomes contagious to all transactions being served by the application. Don’t mute them. Don’t ignore them. Don’t dismiss them. Don’t convince yourself they are harmless. If you want a simple way to improve your applications performance, start by fixing up these regular occurring exceptions. Who knows, you just might help everyone’s code run a little faster.

APM Thought Leadership, application, application monitoring, developers, DevOps, IT operations, runtime exception, slow response error

Interested in winning an iPad? Take our Application Virtualization survey, and we’ll give you a more-than-decent shot at winning your very own!

In talking to our customers, AppDynamics recognizes that virtualizing mission-critical applications is at the top of everyone’s mind, even though some companies are at different stages of the process than others.

Many IT departments have already finished virtualizing their less critical apps and they realize that there are many benefits to be had in virtualizing the rest. But, in many cases, application owners are concerned about performance impacts to their mission-critical apps, and they’re saying, “Hands off my app.”

What’s it like at your organization? Is the path to app virtualization a smooth one, or are you experiencing some bumps along the way? We’d like to find out more, and we’d like your help to do it.

Answer a few short questions on your app virtualization strategy and be automatically entered to win an iPad. In addition, we’ll send you a copy of the results, so you can discover what your peers at other organizations are doing.

Find out:

- What percentage of Tier 1 apps have been virtualized by other companies
- Whether the virtualization project is a stepping stone towards the cloud
- What challenges are preventing people from finishing (or even starting) virtualization of Tier 1 apps

The survey is only 10 questions long–and again, entering gives you the possibility of winning an iPad, as well as a guaranteed copy of the survey results.

Take the survey now!

We look forward to reviewing your responses!

APM Thought Leadership, application, application development, cloud computing, virtualization

I’ve never written a blog post before, but Jyoti tells me, from experience, that if you write about your passion, it’s a piece of cake. So here goes. My passion is to create technology to make application management easier and more productive so that companies can focus on delivering value instead of fretting about just being able to run apps 24×7. Since I intend to keep up this newly acquired habit of mine, let me start by establishing the fundamental tenet on which this technology we build at AppDynamics is based – Business Transactions.

You may think you’ve heard this discussion before, but I’d wager a guess that you’ve actually heard more about transactions than about business. I want to tell you why you actually need to put the focus on the business.

In today’s world where more and more businesses move to the web, the application is the face of the company. It is the business, it is the revenue stream. From DVD rentals to talent management, everything is an online application. Someone suggested to me recently that the only business they cannot use the internet for was getting a haircut. But I am sure they are working on it too!!

From the CIO to the ops team pushing the latest application release out, there needs to be a common context that drives the business unit towards a robust, efficient and a highly competitive application. That context is the business transaction.

Here are a few reasons why you should focus on the ‘business’ side of the business transaction:

1. When the application is the business, competitive advantage means having a better application. Now in an ideal world, when someone builds an application they would like it to be better than anything out there. But having an edge is not a one time thing. It’s constant evolution, which means rapid change and faster adaptation (Flickr does 10+ deployments a day!!). Dynamic changes to an application’s features and functions directly impact the business transaction and the overall user experience. At the end of the day, what you care about most is how your users are being serviced.

2. When the application is the business, managing an application is no longer just about monitoring CPU, JVM memory or timing key methods. It’s really about understanding the user experience, managing the business operations and creating service levels to ensure optimum performance. Business transactions are the binding factor for attaching SLAs to business operations and for creating a common ground between dev teams and ops teams. Focusing on the business transaction is a great way to validate the whole cycle including a rollout or the current state of the app at any given time.  Also, the growth of business means more capacity to serve. This means the growth of servers. So, instead of multiplying management complexity with more resources, a focus on user-centric SLAs is the only scalable way to address performance.

3. When the application is the business, the responsibility of managing applications (and hence the revenue stream) falls on IT Operations. But development is responsible for building the app and for the innovation in it. The creates an interdependence (and what we see as the DevOps movement). By creating a common language to categorize user requests – “Are the checkouts doing ok?” “Is the sales order processing running faster than before?” – these teams are better able to communicate and effectively manage application performance over time.

Using the business transaction as a unit of management for the application makes your company more agile, competitive, scalable and high performance. In future posts, I’ll review the various ways to approach overall application management and take a deeper dive on why a business transaction focus is critical to success.

At the end of the day, it should be all about the business!

APM Thought Leadership, appdynamics, application, application monitoring, DevOps

The debate over who owns an application in production continues to unfurl.  What I’ve found interesting is, after a period of time where writers and bloggers were looking towards IT Operations to be application owners, I’ve started to detect a bit of a backlash.

The arguments for IT Operations owning the application is simple:

• Development should stay focused on creating new applications and adding features, not maintaining what’s already in production
• If you ask a developer, they’ll always say they’d rather spend their time on innovation, rather than production support or bug fixes
• IT Operations generally oversees the production infrastructure (servers, storage, networks etc), so they are the natural caretakers of production applications as well

Analysts often point out that this is easier said that done: what is sometimes called the “required cooperation” between operations and development is often difficult to obtain.  I’ve also seen it suggested that putting production applications in the hands of operations is a Utopian dream, leading to performance issues and SLA violations.

If I were to describe my own view of “natural selection” in regards to managing application performance, it would be more along the lines of collaboration. The development team is likely to help support applications as long as IT Operations is able to provide them with the information and data they need to fix root-cause issues quickly.  Because much development is now done in agile environments, this sort of teamwork is becoming less of a philosophical choice and more of a business necessity.

If you look through blogs and Twitter, you’ll find some interesting grassroots movements such as #devops and #agileoperations.  These are communities forming that acknowledge the need to break down the traditional walls that exist between Dev and Ops, and radically restructure those relationships so that they are focused on shared goals and outcomes.

One devops proponent, James Turnbull at Kartar.net, explains the problem:

“So … why should we merge or bring together the two realms?  Well there are lots of reasons but first and foremost because what we’re doing now is broken.  Really, really broken.  In many shops the relationship between development (or engineering) and operations is dysfunctional to the point of occasional toxicity.”

(I love the phrase “occasional toxicity”…)

He goes on to add:

“DevOps is all about trying to avoid that epic failure and working smarter and more efficiently at the same time. It is a framework of ideas and principles designed to foster cooperation, learning and coordination between development and operational groups. In a DevOps environment, developers and sysadmins build relationships, processes, and tools that allow them to better interact and ultimately better service the customer.

“DevOps is also more than just software deployment – it’s a whole new way of thinking about cooperation and coordination between the people who make the software and the people who run it.  Areas like automation, monitoring, capacity planning & performance, backup & recovery, security, networking and provisioning can all benefit from using a DevOps model to enhance the nature and quality of interactions between development and operations teams.”

I believe that the question that comes naturally out of these conversations is this: does IT operations have the tools they need to facilitate this collaboration with their peers in development?  Traditionally, they haven’t.  The tools either didn’t provide much deep visibility into the application, or when they did provide deep visibility, they were extremely complicated for IT Operations to be able to understand and use. But creating those tools, and encouraging that collaboration, is one of my own company’s guiding principles.

Applications are becoming more complex and distributed, and development is increasingly taking place in the context of agile release cycles.  So really, the question isn’t “who owns the app”–but how best to foster the collaborative process that enables dev and ops to both build out applications and resolve their performance problems, and to do so in record time.

APM Thought Leadership, application, application monitoring, developers, DevOps, IT operations

I haven’t written a blog post before, but I’m told that writing is easy if you write about your passions. So let me discuss why I founded AppDynamics.

I began the company because I saw a gap that I wanted to fill. The world is host to countless thousands of applications, and an almost equal number of people wanting to help IT professionals manage those applications. But somehow, no one ever made managing application performance easy. It was always difficult, complex, and costly.

In addition, most application performance companies were quickly falling behind the times. You may have heard the expression that “nothing dates like science fiction”–it’s easy to look at a science fiction film and instantly know when it was made. Similarly, application performance solutions quickly lose their luster if they’re not constantly adapting to the changing IT environment. What I knew was that distributed applications were becoming more, not less common–and that SOA, virtualization, and the cloud were becoming ever prevalent. Traditional monitoring companies couldn’t keep up with the demands of these new environments.

I wanted to start a company that brought relief to IT professionals who were still on the front lines, managing application performance, but no longer had tools equipped to do the job. I wanted to make managing a complex application as easy as reading a Google traffic map. I wanted to give them the ability to not only monitor application performance, but also find and fix root-cause problems. I wanted to combine traditional monitoring functions with the ability to orchestrate capacity in the cloud.

I won’t use this blog space to only talk about what my company does–I expect to discuss trends in the industry, issues facing IT operations and developers, and other topics that come to mind. But I will always circle back to the bottom line–simplifying the lives of IT professionals by making application performance easy.

Because if you’re supposed to write about your passion, then that is my passion.

appdynamics, application, application development, DevOps