home Contact Customer Jobs
Want to know what's new @ Mu? Enter your email address to receive Mu Dynamics news.

"Finding and fixing security vulnerabilities in network-based systems and applications before they get deployed is critical to staying secure as threats get more targeted and sophisticated. Enterprises need to establish and augment repeatable vulnerability management processes to be more effective at finding complex vulnerabilities and to use tools and technologies to become more efficient at finding and fixing weaknesses before they are exposed on production systems. "

John Pescatore
Vice President & Distinguished Analyst
Gartner Inc.


 |   |   |   |   

Response Time Charts

The ability to graphically compare devices or applications based not only on "hard faults" (e.g., system crashes) but also "soft faults" (e.g., memory leaks, response time degradation, etc.) gives a more complete picture of the relative suitability of a component to a given deployment scenario.  Latency-sensitive applications unable to process valid data in specific timeframes may not meet response-time goals or service level agreements.  

Mu's Response Time Charts interactively expose quality and availability issues to accelerate remediation. Customers can actively gauge a system's ability to maintain control and specific performance levels while processing unexpected inputs.

  Charting Response Time and Latency with the Mu-4000
 
For instance, for an IMS application, it may be tested using Diameter but the effect on the billing system may affect call processing. So not only would the Mu-4000 use valid Diameter traffic (and collect response-time data there), but the Mu-4000 could also use secondary instrumentation and make SIP calls through the IMS cloud to see if the call processing path is affected by the Diameter traffic.

The purpose of the response-time charts is to provide context for the faults, since it's possible that the service could be suffering from degraded response time due to the traffic the Mu-4000 is sending, and that the accumulated effect of this traffic causes a fault much later. The response time charts provide the context to help identify the root cause of the fault. The fault may be the straw that broke the camel's back, but the root cause might be traffic that was not proximal to the fault.

Also, even when there are no faults, the statistics that can be derived from the response time data can be very revealing. A service that offers consistent response times, regardless of how much invalid traffic it receives, may be preferred to one that has highly variable response time. Every provider has their own "threshold of pain:" How high can the response time go before they would say that their service is considered to be impaired?

 
Products | Solutions | Resources | Support | News & Events | Company | Labs | Contact | Home