Opnet http://www.interlinkweb.com/blog/feeds/?t=opnet Opnet Inter-Networking Application Experts http://www.interlinkweb.com/blog/images/interlink.gif Interlink Blog - Inter-Networking Application Experts http://www.interlinkweb.com/blog/ Interlink Custom Generator: vic@interlinkweb.com Ann Schaner aschaner@interlinkweb.com vic@interlinkweb.com <![CDATA[Guest Post - OPNET Application Dependency Maps]]> http://www.interlinkweb.com/blog/post.aspx?=449 http://www.interlinkweb.com/blog/post.aspx?=449 Wed, 02 May 2012 16:09:59 -0600 OPNET LogoRe-posting an OPNET APM Xpert user's recent troubleshooting experience...Run-Time Application Dependency Maps for the Network Team.

It was 8:47am when he got the call.  5 helpdesk incidents reported in a 5 minute period for the recently upgraded portfolio management application.  Massive spikes in user experience.  Angry employees claiming to be paralyzed by "the slow network."

Employees in multiple departments rely on the portfolio manager application to retain customers, make trading decisions, and drive revenue.  As usual, the network team was on the hook to either find the problem or prove "it's not the network."  And because this was a Class A incident, the CIO required real time updates on the troubleshooting status.  Fun.

The good news is that AppResponse Xpert revealed that this was an application problem (not a network problem) right away.  Each transaction seemed to be stuck on a web server, either because the web server had issues or because back end application tiers were help up for some reason. Rather than passing the incident over to the systems team, he decided to dig deeper.

The first hurdle was figuring out which of the 1,000+ systems in the datacenter were talking to the web server for the slow transactions.  He asked three different people involved in managing the application to explain the architecture and dependencies.  No clear answers that made sense emerged.  This was a complicated SOA architecture with lots of moving parts, and no system level alarms provided useful clues.

Based on his knowledge of the front tier, he queried AppMapper Xpert to provide a current multi-tier application dependency map.  10 critical servers apparently hosted different components of the guilty application at run time. But AppMapper also revealed an unexpected relationship:  some load was bypassing the load balancer and going directly to a server named "credit1." Perhaps specific web services had not been correctly configured to hit the load balancer?  Perhaps the upgrade over the weekend had something to do with this?

CPU, memory, and other metrics from SNMP queries seemed normal.  But upon closer inspection with AppResponse Xpert, response time spikes were visible from credit1 that lined up exactly with reported user experience problems, and were not present in the other two systems supporting the credit tier.  Some service calls were likely directed to a single server based on a stale configuration file.  He walked over to the head of development with a PDF showing the dependency map, the load balancer bypass, and the response time spikes in user experience.

10 minutes later, a configuration change was made to the application to drive all traffic to the load balancer.  And that was it.  The rest of the week proved less stressful.

Contact your Interlink Account Manager to find out how to become an OPNET Synergy Partner.

Jacquie

www.interlinkweb.com

]]> OPNET LogoRe-posting an OPNET APM Xpert user's recent troubleshooting experience...Run-Time Application Dependency Maps for the Network Team.

It was 8:47am when he got the call.  5 helpdesk incidents reported in a 5 minute period for the recently upgraded portfolio management application.  Massive spikes in user experience.  Angry employees claiming to be paralyzed by "the slow network."

Employees in multiple departments rely on the portfolio manager application to retain customers, make trading decisions, and drive revenue.  As usual, the network team was on the hook to either find the problem or prove "it's not the network."  And because this was a Class A incident, the CIO required real time updates on the troubleshooting status.  Fun.

The good news is that AppResponse Xpert revealed that this was an application problem (not a network problem) right away.  Each transaction seemed to be stuck on a web server, either because the web server had issues or because back end application tiers were help up for some reason. Rather than passing the incident over to the systems team, he decided to dig deeper.

The first hurdle was figuring out which of the 1,000+ systems in the datacenter were talking to the web server for the slow transactions.  He asked three different people involved in managing the application to explain the architecture and dependencies.  No clear answers that made sense emerged.  This was a complicated SOA architecture with lots of moving parts, and no system level alarms provided useful clues.

Based on his knowledge of the front tier, he queried AppMapper Xpert to provide a current multi-tier application dependency map.  10 critical servers apparently hosted different components of the guilty application at run time. But AppMapper also revealed an unexpected relationship:  some load was bypassing the load balancer and going directly to a server named "credit1." Perhaps specific web services had not been correctly configured to hit the load balancer?  Perhaps the upgrade over the weekend had something to do with this?

CPU, memory, and other metrics from SNMP queries seemed normal.  But upon closer inspection with AppResponse Xpert, response time spikes were visible from credit1 that lined up exactly with reported user experience problems, and were not present in the other two systems supporting the credit tier.  Some service calls were likely directed to a single server based on a stale configuration file.  He walked over to the head of development with a PDF showing the dependency map, the load balancer bypass, and the response time spikes in user experience.

10 minutes later, a configuration change was made to the application to drive all traffic to the load balancer.  And that was it.  The rest of the week proved less stressful.

Contact your Interlink Account Manager to find out how to become an OPNET Synergy Partner.

Jacquie

www.interlinkweb.com

]]> <![CDATA[Guest Post - OPNET AppResponse Xpert]]> http://www.interlinkweb.com/blog/post.aspx?=447 http://www.interlinkweb.com/blog/post.aspx?=447 Tue, 03 Apr 2012 14:35:03 -0600 OPNET LogoHere is another great piece re-posted from the OPNET Experts on OPNET's AppResponse Xpert...From the Trenches:  "Dear Outsourcer, I have visibility into my own app infrastructure now..You missed something!"

Recently, I was onsite at a major pharmaceutical company.  My assignment was to help them use our APM products to solve chronic application performance problems that had plagued multiple key internal applications.  Management of most of their key applications and infrastructure were outsourced, and the provider was unable to adequately respond to their complaints.  "We didn't write your applications, not our problem."  The IT team lacked both visibility and an understanding of the problem to refute such claims. They suspected it was a network problem, however, because so many seemingly unrelated apps were symptomatic.  After several weeks of trying with primitive in-house tools, OPNET received a call from the IT team.

It took me 2 hours to set up and configure AppResponse Xpert, our most popular product and also what most of our clients use for "triage".  Depending on the initial diagnosis, I was prepared to recommend our other APM products to drill deeper into individual application transactions captured from production servers or the network, but seeing all of the apps together is usually the best first step.  AppResponse Xpert was configured to measure end user experience coming into and out of the data center, using live monitoring sessions from SPANs on 4 switches.  Using a unique feature for monitoring interface groups, I could immediately see aggregate stats for traffic on each interface combined, as well as from each interface.  I took note of which transactions were entering the data center from each WAN switch as well as end-user response times for individual web pages and sites.  This led to a brief discussion with the IT department about some interesting observed (and unexpected) patterns of user behavior, but we quickly returned to our investigation..

Our first major clue revealed itself immediately:  disproportionately high number of transactions were entering the company's data center on one switch but served on another.  Asymmetric routing.  I asked the IT staff if this was intended the answer was a resounding "no." Apparently, asymmetric routing was an unintended side effect of the redundant architecture they were sold.  The impact of traffic moving across different ISPs should be inconsistent performance, but not necessarily bad performance.  This mystery was quickly solved by using AppResponse Xpert to compare end user response times for the symptomatic and well-behaved application sites that had otherwise similar bandwith and latency.  The results were conclusive:  a particular ISP was not preforming well, so it made no sense to route parts of each app transaction through that ISP.

Does it make sense to leave the productivity of every employee at this company up to chance?  I didn't think so, and neither did the IT department.  Armed with visibility and knowledge of the root cause, they quickly assigned a specialist to reconfigure the network to consistently route traffic through the right ISPs.  Although I didn't stick around to conduct a survey, I'm sure that their employees breathed a sigh of relief when they arrived at work the next day and noticed that their systems were dramatically more responsive.   The next time a tidal wave of tickets hits the help desk, hopefully a solution is minutes away vs. weeks now that they have AppResponse Xpert monitoring 24x7.

Find out how to be an OPNET reseller today!

Jacquie

www.interlinkweb.com

]]> OPNET LogoHere is another great piece re-posted from the OPNET Experts on OPNET's AppResponse Xpert...From the Trenches:  "Dear Outsourcer, I have visibility into my own app infrastructure now..You missed something!"

Recently, I was onsite at a major pharmaceutical company.  My assignment was to help them use our APM products to solve chronic application performance problems that had plagued multiple key internal applications.  Management of most of their key applications and infrastructure were outsourced, and the provider was unable to adequately respond to their complaints.  "We didn't write your applications, not our problem."  The IT team lacked both visibility and an understanding of the problem to refute such claims. They suspected it was a network problem, however, because so many seemingly unrelated apps were symptomatic.  After several weeks of trying with primitive in-house tools, OPNET received a call from the IT team.

It took me 2 hours to set up and configure AppResponse Xpert, our most popular product and also what most of our clients use for "triage".  Depending on the initial diagnosis, I was prepared to recommend our other APM products to drill deeper into individual application transactions captured from production servers or the network, but seeing all of the apps together is usually the best first step.  AppResponse Xpert was configured to measure end user experience coming into and out of the data center, using live monitoring sessions from SPANs on 4 switches.  Using a unique feature for monitoring interface groups, I could immediately see aggregate stats for traffic on each interface combined, as well as from each interface.  I took note of which transactions were entering the data center from each WAN switch as well as end-user response times for individual web pages and sites.  This led to a brief discussion with the IT department about some interesting observed (and unexpected) patterns of user behavior, but we quickly returned to our investigation..

Our first major clue revealed itself immediately:  disproportionately high number of transactions were entering the company's data center on one switch but served on another.  Asymmetric routing.  I asked the IT staff if this was intended the answer was a resounding "no." Apparently, asymmetric routing was an unintended side effect of the redundant architecture they were sold.  The impact of traffic moving across different ISPs should be inconsistent performance, but not necessarily bad performance.  This mystery was quickly solved by using AppResponse Xpert to compare end user response times for the symptomatic and well-behaved application sites that had otherwise similar bandwith and latency.  The results were conclusive:  a particular ISP was not preforming well, so it made no sense to route parts of each app transaction through that ISP.

Does it make sense to leave the productivity of every employee at this company up to chance?  I didn't think so, and neither did the IT department.  Armed with visibility and knowledge of the root cause, they quickly assigned a specialist to reconfigure the network to consistently route traffic through the right ISPs.  Although I didn't stick around to conduct a survey, I'm sure that their employees breathed a sigh of relief when they arrived at work the next day and noticed that their systems were dramatically more responsive.   The next time a tidal wave of tickets hits the help desk, hopefully a solution is minutes away vs. weeks now that they have AppResponse Xpert monitoring 24x7.

Find out how to be an OPNET reseller today!

Jacquie

www.interlinkweb.com

]]> <![CDATA[Guest Post - OPNET Citrix Application]]> http://www.interlinkweb.com/blog/post.aspx?=446 http://www.interlinkweb.com/blog/post.aspx?=446 Mon, 26 Mar 2012 16:03:01 -0600 OPNET LogoInterlink is re-posting an interesting piece from OPNET Experts on a new approach for Citrix Application Performance Monitoring and Troubleshooting.  Solving performance problems for applications served through Citrix XenApp can be daunting.  While Citrix fixes many problems related to application management and performance, it can also make troubleshooting a bit more complicated.

In the past, troubleshooting Citrix-related bottle necks was a time-consuming process wherein a successful outcome depended largely on the experience of the analyst.

When users complain about slowness across Citrix servers, sometimes there are obvious culprits.  For example, a particular XenApp server may be oversubscribed in terms of CPU or memory, the WAN connection between the user and the XenApp may be congested, or the backend application may be overutilized.  After reaching for all the low hanging fruit and coming up empty, the next step is to take a closer look at the individual user sessions.

Typically, investigating user transactions in Citrix involves downloading packet data at each hop along the path between the end-user, the XenApp server, and the backend application.  Packet analysis across Citrix XenApp is always a time consuming process that is sometimes impossible (e.g. when the packets aren't available, or the payload is encrypted).  Even when the data is available to analyze, the interpretation of the data is subjective; there is no common information shared between the front-end Citrix session packets and the backend application traffic.  The mapping between front-end Citrix session and backend application boils down to an educated guess, at best.  For these reasons, analyzing user transactions was seen as a "hail mary pass" that should be approached with caution.

Fortunately, OPNET recently released a new product, CX-Tracer TM, which drastically changes the approach to Citrix monitoring and troubleshooting.

CX-Tracer TM automatically traces every end-user transaction through the Citrix server and into the backend application with perfect accuracy.  Identifying the root cause of a performance bottleneck with CX-Tracer is much faster than the old workflow.  Typically, a root cause determination can be made within a few minutes.  After being alerted to a problem, the troubleshooter can jump directly to a clean, end-to-end transaction trace that spans from the desktop, through the XenApp server and into the backend application.  This transaction trace will conclusively point the finger at the bottleneck.  Most often the slowness is related to the backend application rather than the Citrix sever or the WAN connection.  In this case CX-Tracer automatically integrates with OPNET's APM suite to correlate the user transaction with delays in SQL and other application protocols.

The new OPNET CX-Tracer product is a blessing for anyone who troubleshoots performance issues across Citrix frequently.  The product is valuable, not just because it saves, time, but because it takes the guesswork out of the analysis and brings Citrix application performance management into the realm of science rather than art.

For more info, contact your Interlink Account Manager and ask them about OPNET.

Jacquie

www.interlinkweb.com

]]> OPNET LogoInterlink is re-posting an interesting piece from OPNET Experts on a new approach for Citrix Application Performance Monitoring and Troubleshooting.  Solving performance problems for applications served through Citrix XenApp can be daunting.  While Citrix fixes many problems related to application management and performance, it can also make troubleshooting a bit more complicated.

In the past, troubleshooting Citrix-related bottle necks was a time-consuming process wherein a successful outcome depended largely on the experience of the analyst.

When users complain about slowness across Citrix servers, sometimes there are obvious culprits.  For example, a particular XenApp server may be oversubscribed in terms of CPU or memory, the WAN connection between the user and the XenApp may be congested, or the backend application may be overutilized.  After reaching for all the low hanging fruit and coming up empty, the next step is to take a closer look at the individual user sessions.

Typically, investigating user transactions in Citrix involves downloading packet data at each hop along the path between the end-user, the XenApp server, and the backend application.  Packet analysis across Citrix XenApp is always a time consuming process that is sometimes impossible (e.g. when the packets aren't available, or the payload is encrypted).  Even when the data is available to analyze, the interpretation of the data is subjective; there is no common information shared between the front-end Citrix session packets and the backend application traffic.  The mapping between front-end Citrix session and backend application boils down to an educated guess, at best.  For these reasons, analyzing user transactions was seen as a "hail mary pass" that should be approached with caution.

Fortunately, OPNET recently released a new product, CX-Tracer TM, which drastically changes the approach to Citrix monitoring and troubleshooting.

CX-Tracer TM automatically traces every end-user transaction through the Citrix server and into the backend application with perfect accuracy.  Identifying the root cause of a performance bottleneck with CX-Tracer is much faster than the old workflow.  Typically, a root cause determination can be made within a few minutes.  After being alerted to a problem, the troubleshooter can jump directly to a clean, end-to-end transaction trace that spans from the desktop, through the XenApp server and into the backend application.  This transaction trace will conclusively point the finger at the bottleneck.  Most often the slowness is related to the backend application rather than the Citrix sever or the WAN connection.  In this case CX-Tracer automatically integrates with OPNET's APM suite to correlate the user transaction with delays in SQL and other application protocols.

The new OPNET CX-Tracer product is a blessing for anyone who troubleshoots performance issues across Citrix frequently.  The product is valuable, not just because it saves, time, but because it takes the guesswork out of the analysis and brings Citrix application performance management into the realm of science rather than art.

For more info, contact your Interlink Account Manager and ask them about OPNET.

Jacquie

www.interlinkweb.com

]]> <![CDATA[Guest Post - OPNET APM]]> http://www.interlinkweb.com/blog/post.aspx?=444 http://www.interlinkweb.com/blog/post.aspx?=444 Thu, 22 Mar 2012 10:54:45 -0600 OPNET Logo

Interlink is pleased to re-post an excellent piece from OPNET Experts on Application Performance Management Best Practices for Migration Projects.  Gartner recognized OPNET in the Leader's Quadrant in the "Magic Quadrant for Application Performance Monitoring".

Interlink is OPNET's SYNERGY Program Distributor in North America.  As a two-tier solutions provider for advanced technologies such as traffic visibility and application performance management (APM), Interlink is well positioned to assist with your OPNET sales opportunities.

Industry Perspective: APM Best Practices for Migration Projects

Over the years we have learned quite a bit about making application migrations successful. Enterprises often seek our expertise on how to apply APM technologies at different phases of migration projects. Our partners often seek assistance with filling gaps in their broader service offerings related to server consolidation and virtualization, datacenter outsourcing, cloud computing, and network services. Here is a greatly simplified list of questions that APM can address:
  • Will the migration be successful? Will applications perform?
  • How best to execute the migration?
  • How to manage performance once the project is complete?
Given the recent burst of interest in this area, we thought it might be useful to share some best practices, illustrated with an example. The example is based on a successful project we did for a large government agency, which is similar to other projects we have participated in for commercial and government enterprises around the world.

This customer was convinced of the operational and cost advantages of a well-publicized datacenter consolidation project, but serious concerns about application performance prevented progress. The customer had a loosely documented application architecture, and limited visibility into application performance. Here is what we recommended and implemented:
  1. Application Performance Baselining. Before migration to a consolidated datacenter, characterize application usage and behavior. Data collected by APM solutions can help to accurately size the new infrastructure, eliminate pre-existing performance problems, and determine which applications are suitable for migration.
  2. Application Dependency Mapping. A clear understanding of the intricate front and back end client-server relationships is vital to executing the migration since physically separating highly dependent application tiers can cause serious performance degradations (or in some cases, complete failures). Ideally, clear run-time dependency maps should be automatically assembled from the APM instrumentation already in place from the baselining exercise.
  3. Application Migration Planning. Once the applications suitable for migration have been identified and their dependent components reviewed, predictive analysis on key application transactions should provide accurate insight into post-migration performance. The models used for this analysis are driven by a few key parameters of the infrastructure, as well as application profiles captured from the live environment (before the migration).
  4. Post-Migration, Production Monitoring. After migration, it’s important to verify that performance objectives are met on an on-going basis, and when they are not, why not? This is particularly important when a new department or service provider is involved, for obvious reasons. Who is responsible? What to do? The most meaningful way to monitor application performance is from an "end user transaction" perspective rather than solely from a resource perspective. APM technologies can make it easy to see individual user transactions for multi-tier applications through SSL, through Citrix sessions, across virtual and physical systems, and to highlight specific database or web queries. When considering how to monitor application performance from the end user’s perspective, you may find it useful to review Russ' prior blog post ("Making Sense of End User Experience Monitoring").

By implementing best practices, this customer and many others have achieved success.

Contact Interlink today to learn how you can partner with OPNET.

Ann

www.interlinkweb.com

]]> OPNET Logo

Interlink is pleased to re-post an excellent piece from OPNET Experts on Application Performance Management Best Practices for Migration Projects.  Gartner recognized OPNET in the Leader's Quadrant in the "Magic Quadrant for Application Performance Monitoring".

Interlink is OPNET's SYNERGY Program Distributor in North America.  As a two-tier solutions provider for advanced technologies such as traffic visibility and application performance management (APM), Interlink is well positioned to assist with your OPNET sales opportunities.

Industry Perspective: APM Best Practices for Migration Projects

Over the years we have learned quite a bit about making application migrations successful. Enterprises often seek our expertise on how to apply APM technologies at different phases of migration projects. Our partners often seek assistance with filling gaps in their broader service offerings related to server consolidation and virtualization, datacenter outsourcing, cloud computing, and network services. Here is a greatly simplified list of questions that APM can address:
  • Will the migration be successful? Will applications perform?
  • How best to execute the migration?
  • How to manage performance once the project is complete?
Given the recent burst of interest in this area, we thought it might be useful to share some best practices, illustrated with an example. The example is based on a successful project we did for a large government agency, which is similar to other projects we have participated in for commercial and government enterprises around the world.

This customer was convinced of the operational and cost advantages of a well-publicized datacenter consolidation project, but serious concerns about application performance prevented progress. The customer had a loosely documented application architecture, and limited visibility into application performance. Here is what we recommended and implemented:
  1. Application Performance Baselining. Before migration to a consolidated datacenter, characterize application usage and behavior. Data collected by APM solutions can help to accurately size the new infrastructure, eliminate pre-existing performance problems, and determine which applications are suitable for migration.
  2. Application Dependency Mapping. A clear understanding of the intricate front and back end client-server relationships is vital to executing the migration since physically separating highly dependent application tiers can cause serious performance degradations (or in some cases, complete failures). Ideally, clear run-time dependency maps should be automatically assembled from the APM instrumentation already in place from the baselining exercise.
  3. Application Migration Planning. Once the applications suitable for migration have been identified and their dependent components reviewed, predictive analysis on key application transactions should provide accurate insight into post-migration performance. The models used for this analysis are driven by a few key parameters of the infrastructure, as well as application profiles captured from the live environment (before the migration).
  4. Post-Migration, Production Monitoring. After migration, it’s important to verify that performance objectives are met on an on-going basis, and when they are not, why not? This is particularly important when a new department or service provider is involved, for obvious reasons. Who is responsible? What to do? The most meaningful way to monitor application performance is from an "end user transaction" perspective rather than solely from a resource perspective. APM technologies can make it easy to see individual user transactions for multi-tier applications through SSL, through Citrix sessions, across virtual and physical systems, and to highlight specific database or web queries. When considering how to monitor application performance from the end user’s perspective, you may find it useful to review Russ' prior blog post ("Making Sense of End User Experience Monitoring").

By implementing best practices, this customer and many others have achieved success.

Contact Interlink today to learn how you can partner with OPNET.

Ann

www.interlinkweb.com

]]> <![CDATA[Gartner Recognizes OPNET in Leader's Quadrant]]> http://www.interlinkweb.com/blog/post.aspx?=435 http://www.interlinkweb.com/blog/post.aspx?=435 Mon, 26 Sep 2011 16:45:07 -0600 OPNET LogoWe are excited to share that Gartner recognized OPNET in the Leader's Quadrant in the "Magic Quadrant for Application Performance Monitoring".  Read the Gartner Report. 

OPNET's AppResponse Xpert™, AppTransaction Xpert™, and AppInternals Xpert™ are particularly well suited for channel sales, with fast deployment, and a very clear and compelling value proposition and rapid ROI.

Ask your Interlink Account Manager how you can become an OPNET Synergy Partner today!

Gartner Application Performance Monitoring Report

Become an OPNET Synergy Partner

Jacquie Stovern

www.interlinkweb.com

]]> OPNET LogoWe are excited to share that Gartner recognized OPNET in the Leader's Quadrant in the "Magic Quadrant for Application Performance Monitoring".  Read the Gartner Report. 

OPNET's AppResponse Xpert™, AppTransaction Xpert™, and AppInternals Xpert™ are particularly well suited for channel sales, with fast deployment, and a very clear and compelling value proposition and rapid ROI.

Ask your Interlink Account Manager how you can become an OPNET Synergy Partner today!

Gartner Application Performance Monitoring Report

Become an OPNET Synergy Partner

Jacquie Stovern

www.interlinkweb.com

]]>