AppNeta | The Path

Posts Tagged ‘Remote Monitoring

On September 29th, we experienced a large amount of poor call quality here at the Apparent Networks Boston headquarters.  Our sales team was unable to engage in communications and was quickly losing productivity.  With the VoIP server hosted at our remote office in Vancouver, there could have been any number of reasons why this was occurring.  However, PathView Cloud was able to provide our engineers with the full story before the sales team could even react.

PathView Cloud told us that our recent firmware upgrade had wiped the QoS settings we had deployed for our VoIP system allowing other network traffic to take precedence over our telephony packets in the VPN tunnel connecting our two offices, resulting in poor call quality and dropped calls. Click here to take a live look at our business production servers!

Advertisements

If you’re suffering from slow application performance, chances are you’re suffering from some degree of latency.  As everyone knows, each computer has its own performance limits.  With one too many applications, lag will result from the inability of the computer to process all of its inputs. If the application relies on connectivity with some type of remote device, such as a back-up service, an exchange e-mail server or even just video chatting with a colleague over the internet, the performance disruption or failure is a result of the network, rather than the hardware.

The latency on your network defines the minimum wait time before the person or service on the other end receives the packets you send. For a connection between New York and Los Angeles, the minimum possible latency is typically 40ms. In many cases, network traffic and misconfigurations can dramatically increase this time.

However, when it comes to cloud based applications, such as the CRM application we use here at Apparent Networks, both of these factors come into play and exponentially increase response time as they suffer performance losses. The local client for cloud based applications is usually a thin client, or even a web-browser client that only relays inputs to the actual application running on a machine on the cloud.  In this case, latency is the lag time for a signal to reach the server (for the NY to LA example, this would be at the lowest 40ms) the processing time for the server to create a response, and the time for it to be sent back to the client machine.

This increase in response time is also exacerbated when the application is an ‘on demand’, or live application, that requires packets to be sent upstream then received downstream whenever an action is taken.  An example of this is a virtualized desktop.  Because even the smallest action requires data to be sent, each individual action will be subject to the round trip latency on your network.

Latency is a problem – and one that we can’t afford to risk. So how do we ensure that latency stays at a minimum? For managed devices and services, optimization is up to the service provider. For localized devices and services, there are a plethora of tools that can determine and alert you on service quality drops.  However, with an increasingly network dependant world, how do we detect and address increases in response time on our carrier networks and externally managed services?

Without a network monitoring tool that can determine exactly what the problem is and pinpoint where on the network it is happening, troubleshooting is virtually impossible.  If the performance issue is occurring because of a lack of bandwidth, searching for lagging devices will not help.  If the latency is occurring across the WAN, you have no power to make optimizations without proof. PathView Cloud is one tool that manages network performance, including latency, up the path to remote applications and back to the source to detect real time changes in network performance. Learn more about PathView Cloud’s reporting capabilities here!

One of the big questions that we hear all the time is “how do you differentiate from other remote monitoring tools?” And, with an ever-changing IT environment and many solutions on the market, we understand why this is such an important question to answer.  As well as the more important question to answer – why should you care?

Remote Monitoring Management (RMM) products allow for the deployment of applications off premise.  This is crucial to maintain stability at the workstations.  Though, when it comes to network performance, an RMM tool has limited resources.  A well positioned tool is only able to capture limited SNMP statistics.  SO at the end of the day, the questions still remains, how is my network performing?

In the Apparent Networks office here in Boston, we’re always buzzing about Remote Performance Management (RPM) – what we think is a critical component of network monitoring. Traditional Remote Monitoring Management tools focus on making sure your managed services stay up and running, but lose their edge when it comes to pinpointing the cause of performance degradation, where RPM really shines.

The PathView Cloud Remote Performance Management solution uniquely creates and sends packets to any specified IP-addressable end-point, proactively experiencing the performance of the entire network path – every minute!   By framing the network in its entirety rather than pin-pointing “data collection points” the problems of the aforementioned methods can be avoided. With such a tool the business sensitive health and performance of the network can genuinely be gauged.

So why should YOU care? Whether you are managed service provider or you are managing an internal IT dept. RPM must be part of your toolkit. RPM provides you with a tool that not only quickly pre-assesses networks to reveal potential problems before deployment, it also provides continuous monitoring to determine the source of performance issues and enables you to fix them – to lessen the impact on end users.

Click here to learn more about the PathView RPM approach to network monitoring.


Follow us on Twitter!

Error: Twitter did not respond. Please wait a few minutes and refresh this page.

%d bloggers like this: