STOP the Finger Pointing: App vs. Network

6
9

Written by: Meryl Robin, Director of Virtual Solutions, Radware Inc and Yaron Azerual, Product Marketing Manager, Radware Inc.

The challenges of application slowdown: Identify where the slowdown occurs and why. Give your users unmatched QoE and routinely meet the highest level of SLA

We should discuss what the main goal for deploying an ADC is: 95% of the time, it is to enforce increasingly more stringent application SLA’s. To achieve this, we have to consider improving application availability, whether you’re solving local server failure with local server load balancing or fixing global downtime through GSLB with a DR site. It’s also important to improve performance by offloading some of the CPU intensive tasks from the server to the ADC, like SSL, compression, or even smart caching (dynamic caching for even faster response time of the application).

Even after the best ADC solution is deployed though, the challenge of monitoring the prescribed SLA’s remains. It’s rather simple to detect an incident of application unavailability: it is either responding or not. If not, it is sending an error message. Some ADCs will alert you when the application is no longer available, but that is already too late.

Application slowdown on the other hand is much harder to detect (users are not often timing the application, and can’t know what an “out of SLA” response time may be), and can often go unnoticed for long periods of time. The result can be tremendous harm to business execution and even employee productivity (in case of internal enterprise applications) due to lower conversion rates, customer satisfaction and loyalty.

The time has come where we can monitor live traffic and have automated plans in place, at the ready to launch, avoiding unnoticed application slowdown.

The most painful challenge of receiving alerts for an application slowdown and more importantly of user experience, is understanding the slowdown’s source, and this requires a much more advanced solution.

Application Performance Monitoring (APM) is an essential tool to help IT administrators gain visibility into their application’s performance and maintain their application’s SLA actively in real time. It is important to subscribe to the proactive planning approach for potential events or as an occurrence arises, rather than reactive responses after the problem persists, which will potentially cause serious financial damage.

Traditionally, the approaches for deploying an APM solution have been twofold:

  1. Synthetic tools that run predefined scripts to browse your web application and measure its response time/availability
  2. Dedicated software agents installed on each of the application’s server and collects performance measurements per each user and transaction on the server

The first option was the most cost effective, and required relatively little integration with the application; just running a non-intrusive script per application. However, it is also a very limited tool that can only run “read” transactions and not in real time. It does not run “write” transactions, as this can alter production data. Coverage of applications in real-time use (the actual transactions being used/the actual user experience) is very poor.

The second option provides a high-end solution with excellent coverage of the actual user experience per use/transaction with a very detailed breakdown for accurate root cause analysis. Though it is also much more expensive to deploy as a first time investment, and in risk, as it often requires deep integration with the servers’ OS in the production environment.

Imagine if you could combine the benefits of both options above in one simple and more cost effective solution. Imagine that your Application Delivery Infrastructure could also provide an APM tool that can:

  • Monitor the performance of your servers
  • Monitor the performance of the network between your DC and the user
  • Monitor the actual user experience – response time, errors etc.
  • Correlate the results between many users, many transactions, application load etc.
  • Provide one central APM console, that shows processed information collected from several applications in multiple datacenters
  • Alerts you when a specific transaction (or group of transactions) is out of its designated SLA.
  • Provides you with all the relevant information for root cause analysis

Radware’s APM solution delivers the best of all worlds. The statistics collection function is embedded in the ADC. This is the best place to embed this function, as it oversees all servers as well as all users.

Radware’s APM solution uses a leading reporting engine delivering intuitive and easy to understand reports, which are all focused on detecting and alerting for any application SLA deviation.

No longer does the IT admin have performance statistics thrown at him to be told to figure out if and where a problem may originate. Effective SLA related root cause analysis require drilldown-able and historic data combined with the correlation of the application load, and delay measurements breakdown between DC, network, and user.

So if you are a network administrator receiving complaints from one of the application administrators that the network is causing application slowdowns again, or if you are on the apps team and the network guy is telling you it is not the network but rather the app, the resolution will be clear. Both teams will easily see which part of the application delivery chain is the offender and contributing to a delay, and where the work is needed to get done, leading to the application’s SLA/response time becoming back on track.

Radware’s ADC solution offers a new and holistic approach to application SLA assurance: It provides both the tools for application availability and acceleration as well as an integrated/embedded APM best of breed solution to provide the important application performance visibility required to ensure continuous optimized application performance.

6 COMMENTS

  1. Did you see the recent Citrix annoucement to open up Netscaler. Sounds very forward thinking, and the direction the overall market may be moving towards. Can VADI do the same or be reearchitected to dothe same?

  2. the simple answer to your question is yes – VADI can provide all of this information.

    but it does it in a more useful way: it processes all of this info to give the application admin the details he require to understand the QoE his application actually providing and to pin point a problem when one of his application’s transaction breaches a predefined SLA:

    the secret souse in Radware’s solution is an advanced reporting engine that processes and presents the statistics our ADC gather per application/server/ browser/geo/os etc…

  3. Could VADI in theory be able to run on Cisco Nexus platform as a service? Much like the recent announcement of Imperva and their WAF. If so, with Cisco’s recent decision to exit/de-emphasize their ACE platform, should this not be an opportunity for Radware?

    • I think Cisco’s recent announcement is an opportunity for Cisco’s customers to upgrade their ADC infrastructure to one of the leading solutions like the one from Radware. it’s a nice business opportunity for Radware…

LEAVE A REPLY

Please enter your comment!
Please enter your name here