One of our partners recently outlined a logical framework for evaluating Application Performance Management (APM) vendors to help prospects and customers choose the right APM solution for their needs.

Below is an extract along with a link to the full article:

“We work with a lot of customers helping them with performance and scalability of their mission-critical web applications. One of the common requests we hear, is to have a logical framework around how to evaluate the different commercial Application Performance Management products in the market. We have a very easy strategy with our tools and partners at codecentric: We are always partner with the best available solution in the market! We have been a partner with Quest Software (PerformaSure, Foglight), then Wily (Introscope) until they were acquired by CA, then dynaTrace and now AppDynamics is our main partner for APM solutions. We have a lot of knowledge on all of these tools and competition and try to be as neutral a possible. With this article I will try to give my view of how to compare APM solutions for production environments and also my view on how some of the available solutions compare.”

Read the full post by Mirko Novakovic at Code-Centric:

http://blog.codecentric.de/en/comparing-appdynamics-vs-dynatrace-ca-wily-precise-and-hp/

apm, appdynamics, application monitoring, Application Performance Management, BTM, CA Wily, Comparing AppDynamics vs, Dynatrace, Evaluating APM, HP, Precise

There are many technical articles/blogs on the web that jump straight into areas of .NET code you can instantly optimize and tune. Before we get to some of those areas, it’s good to take a step back and ask yourself, “Why am I here?” Are you interested in tuning your app, which is slow and keeps breaking, or are you looking to prevent these things from happening in the future? When you start down the path of Application Performance Management (APM), it is worth asking yourself another important question – what is success? This is especially important if you’re looking to tune or optimize your application. Knowing when to stop is as important as knowing when to start.

A single code or configuration change can have a dramatic impact on your application’s performance. It’s therefore important that you only change or tune what you need to – less is often more when it comes to improving application performance. I’ve been working with customers in APM for over a decade and it always amazes me how dev teams will browse through packages of code and rewrite several classes/methods at the same time with no real evidence that what they are changing will actually make an impact. For me, I learned the most about writing efficient code in code reviews with peers, despite how humbling it was. What I lacked the most as a developer, though, was visibility into how my code actually ran in a live production environment. Tuning in development and test is not enough if the application still runs slow in production. When manufacturers design and build cars they don’t just rely on simulation tests – they actually monitor their cars in the real world. They drive them for hundreds of thousands of miles to see how their cars will cope in all conditions they’ll encounter. It should be the same with application performance. You can’t simulate every use case or condition in dev and test, so you must understand your application performance in the real world.

Read the Full Post…

.NET Application Performance, .NET Best Practise, .NET Exceptions, .NET Performance, .NET SQL Statements, .NET Topology, apm, Application Performance Management, Azure Monitoring, IIS Monitoring

In my previous blog I’ve written about the hard work needed to successfully migrate applications to the cloud.   But why go through all that work to get to the cloud? It’s to take advantage of the dynamic nature of the cloud with the ability (and agility) to quickly scale applications. Your application’s load probably changes all day, all week, and all year. Now your application can utilize more or less resources based on the changes in load. Just ask the cloud for as much computing resources that you need at any given time, and unlike at data centers, the resources are available at the push of a button.

But that only works during the marketing video. Back in the real world, no one can find that magic button to push. Instead scaling in the cloud involves pushing many buttons, running many scripts, configuring various software, and then fixing whatever didn’t quite work. Oh, and of course even that is the easy part, compared to actually knowing when to scale, how much to scale and even what parts of your application to scale. And this repeats all day, every day, at least until everyone gets discouraged.

Read the Full Post…

apm, APM Analytics, Cloud Bursting, cloud computing, cloud orchestration, Private Cloud, Public Cloud, Scaling Apps

application monitoring, cloud computing, cloudfail, public clouds

Many root causes ago I was working with a customer who suspected they had a memory leak in production. Their JVM console event logs were showing the famous OutOfMemory exception and these were being thrown periodically every three to four days causing production outages. To stop these exceptions, the operations team would restart all JVMs at midnight every night in order to prevent system wide impact to customers during business hours. And if Ops forgot to restart the JVMs (which they did on several occasions), production went bang.

It’s worth pointing out at this stage that “OutOfMemory” exceptions in log files doesn’t automatically mean your application has a memory leak. It simply means your application is using or needs more memory than you’ve allocated to it at run-time. A leak is just one candidate of several potential candidates that cause memory to grow over time until all resource is exhausted.

Read the Full Post…

apm, Application Performance Management, Heap Dump, Java Memory Leak, Memory Profiler, Out of Memory, OutOfMemory Exception

Agile & DevOps, apm, Application Complexity, Application Performance Management, cloud, MTTR, SOA, Solving Performance

Attendees of the 2010 Gartner Data Center Conference exhibited a lot of interest around Application Performance Management, as evidenced by the packed room where Gartner analyst Donna Scott discussed application availability in her session “Uptime All the Time.”

Read the Full Post…

APM Thought Leadership, application monitoring, DevOps

AppDynamics is spending the week in Las Vegas–or, as our Southwest pilot wisecracked as our plane descended, “Lost Wages.” But it’s not for fun—at least, not that kind of fun. We’re talking to prospects and customers at the 2010 Gartner Data Center conference.

Read the Full Post…

cloud computing, infrastructure, IT operations, virtualization

AppDynamics is founded on a set of deeply held beliefs regarding our industry and how it’s changed over the last several years.  But it’s never good to let deeply held beliefs stay unchallenged.  So every now and then, we do a reality check.

Our most recent reality check was during our webinar presentation of AppDynamics 3.0. We attracted hundreds of IT ops and dev professionals who wanted to learn both about our solution as well as the specific features of our new release—so we took the opportunity to poll them and ask them a few questions. First, we asked if they operated in a SOA environment:

AppDynamics believes that applications are increasingly moving to SOA, turning monolithic web architectures from the early 2000s into obsolete antiques.  As you can see, that belief was confirmed; the vast majority of our webinar attendees have already entered that world.

Then we asked if they followed an agile development approach:

Again, the vast majority of attendees have embraced agile—in fact, nearly 50% release new features or capabilities at least monthly!  Only 8% report that they follow the traditional, waterfall approach to development. With those kinds of tumultuous deadlines, AppDynamics remains impressed that these hardy souls were actually able to take enough time out of their schedule to watch our presentation.

Finally, we wanted to know the punch line: what’s the effect of all this change on their ability to manage application performance?

Over half were really feeling the crunch, and only a scant few had escaped unscathed.

It’s not that AppDynamics enjoys the pain of others. (We don’t. Really.)  But having our fundamental beliefs confirmed—that the world of applications has changed, and application management solutions need to change with them—simply lets us know that we exist for the right reasons.

Take the example of one of our most recent customers, TiVo.  Operating in a highly distributed environment, TiVo has hundreds of individual Java and proprietary applications, designed to work together to deliver service to its customers.

“We used to spend hours troubleshooting issues,” Richard Rothschild, Senior Director of IT, told us.  “If a service was running slowly and we didn’t know the cause, finding that root cause was like looking for a needle in a haystack.

He continued, “We used to spend up to 6 hours on root cause. AppDynamics brought that time down to ten minutes.  We’ve already seen a big improvement in the reliability and uptime of our services—anything that simplifies our job in this complex environment makes us feel much more confident about taking on new business projects.”

It’s complicated out there, and with the advent of cloud and virtual environments, it’s not getting any easier. But we went into this business in order to simplify application performance management and support application teams in their quest for both performance and availability.  So far, it looks like we chose the right reasons to exist.

APM Thought Leadership, appdynamics, cloud computing, IT operations, SOA

Here’s a guest blog from one of AppDynamics’ international partners, Stefan Zoltai from sysPerform. Stefan wanted to write about how he used AppDynamics to solve a performance problem for a major telecom company in Switzerland—and we said, sure!  Take it away, Stefan…

I’d like to talk about how we used AppDynamics for a major production troubleshooting exercise—and how AppDynamics passed with flying colors.

Swisscom is the leading telecommunications company in Switzerland with about 5.7 million mobile customers and 1.8 million broadband connections. Swisscom is present on the Swiss market with a full portfolio of wireless, wire- and IP-based data and voice-based communication services.

Swisscom’s (Internet) Messaging had engaged sysPerform to assist with the analysis of their Tomcat 6 / Java 1.6 based WebMail application. WebMail has been under scrutiny for about a year now—ever since it manifested both performance and stability problems. Prior analysis efforts, conducted with a number of available tools, did not lead to the determination of the actual root cause(s) since the aforementioned problems only occurred in production under load and could not be reproduced in other environments. WebMail is rated at a throughput of 300 tx/sec.

We realized immediately that without a deep, detailed view into the application’s runtime, in production and under load, we would not be able to determine the actual root cause.

To analyze the application, we selected AppDynamics’ application performance management solution.  Since this solution has been developed specifically for high throughput, distributed production environments, we were able to obtain a high-level overview of the application as well as conduct a deep root cause analysis down to code-level execution without generating measurable overhead. Again, we did all of this at 300 transactions per second of throughput.

Thanks to AppDynamics’ ability to create a dynamic baseline of application performance, we were able to isolate the major bottlenecks on the first day and discuss a solution with the developers at Swisscom.  We were able to quickly learn the application’s performance and stability characteristics — and after only 5 days of development, we deployed a specific, major fix to address the main issue and massively improve performance.  At the moment, we are continuing our analysis efforts since stability and performance are the focus of an ongoing quality process.

[UPDATE: For Swisscom's perspective on the use of AppDynamics, check out Mika Borner's blog]

This example clearly demonstrates that operating a modern, distributed application without an adequate monitoring solution is effectively the same as “flying blind.” 60%-80% of all performance problems are caused by the application itself, and need to be analyzed from the inside out. We can confirm these numbers from many of other engagements with similar customers. External causes like hardware or network issues have become increasingly rare; it’s the problems deep inside the application that truly matter.

Intelligent application performance management however is not a means to itself, but must be evaluated in terms of economical considerations as well. Our experience indicates that an APM solution shows an ROI within just a few months. Among the reasons for such a quick ROI is the aforementioned extremely fast root cause analysis.

If you’re reading this in Switzerland, feel free to contact me with questions!

– Stefan Zoltai, Founder, SysPerform GmbH

Email: sz@sysperform.ch

Twitter: http://twitter.com/SysPerform

APM Thought Leadership, appdynamics, application monitoring, business transaction, dynamic baselines