{"id":1509,"date":"2014-03-24T05:16:19","date_gmt":"2014-03-24T09:16:19","guid":{"rendered":"http:\/\/blog.eginnovations.com\/?p=1509"},"modified":"2022-08-18T10:01:30","modified_gmt":"2022-08-18T14:01:30","slug":"web-performance-monitoring-challenges","status":"publish","type":"post","link":"https:\/\/www.eginnovations.com\/blog\/web-performance-monitoring-challenges\/","title":{"rendered":"Web Application Performance Monitoring –
Two Challenges you need to tackle to solve the "It’s Slow" problem"},"content":{"rendered":"

\"Graphic<\/p>\n

As an application owner or architect, have you been in situations where the users complain that the Web Application is slow, but there is no clear root cause?<\/p>\n

How do we go from finger-pointing and hit-and-miss troubleshooting to pin-pointing the root cause?<\/p>\n

This blog post frames the problem statement and outlines two key challenges that you need to tackle and resolve. Stay tuned as we dive into potential solutions in future blog posts.<\/p><\/blockquote>\n

.<\/p>\n

Webinar: Best Practices to Solve Application Slowdown<\/a><\/div>\n

<\/span>A typical “It’s Slow” Scenario<\/strong><\/span><\/h3>\n

The other day, I was talking to an IT Director of a leading multi-national bank, who explained his monitoring challenges which you may be able to relate to.<\/p>\n

\n

Case Study<\/strong><\/p>\n

The application is a typical multi-tier architecture built using multiple technologies. Multiple load balancers, web servers, application servers, backend web services, message queues and databases.<\/p>\n

Users would always complain that the service is slow.<\/p>\n

The organization had a ton of infrastructure tools that captured metrics for CPU, Memory and Disk. In addition, each team had point-products specific to their domain (middleware, database, network etc.).<\/p>\n

As stated by the IT Director:<\/p>\n

“Every time users complained of slowness, we would assemble a war room – all hands on deck. What’s frustrating for me is that although we have multiple cross-functional teams jumping in – nothing specific or actionable emerges.”<\/em><\/p>\n<\/div>\n

You’ve been in these situations before. Why is pinpointing root cause in a multi-tier Web Application such a pain?<\/p>\n

There are several reasons – but it all boils down to this:\u00a0Lack of holistic and coherent end-to-end performance monitoring and management perspective. I’ve outlined a flavor of the key challenges which we’ll explore in-depth in future blog posts.<\/p>\n

<\/span>Challenge #1: Symptoms Everywhere, Root Cause Nowhere<\/strong><\/span><\/h3>\n

Most application performance<\/a> management and monitoring is silo-based. When performance problems occur, each siloed team looks at point products in their own domain.<\/p>\n

In a multi-tier application, there are complex inter-dependencies. There is a ripple effect of problems that cascade across tiers. Teams get caught up in troubleshooting the symptoms without understanding where the root-cause lies. Often, this leads to long troubleshooting cycles and increases the Mean Time To Repair (MTTR).<\/p>\n

\"Graphic<\/a>

Multi-tier applications have complex inter-dependencies.
Can you quickly pinpoint root cause from a variety of symptoms?<\/p><\/div>\n

<\/span>Challenge #2: “Ain’t My Problem” syndrome<\/strong><\/span><\/h3>\n

Sometimes, the exact opposite happens.\u00a0Each silo team lives in their island with their own tool-sets:<\/p>\n