pointer

Monthly Archives: May 2011

Four Factors That Affect Your Network Performance

Solving issues related to poor Application Response Time (ART) is a key task that network engineers have to tackle all the time. Is it the application itself or a slow network that is driving users mad? Maybe it’s the server that’s simply stalling too much?

Finding the cause of your users’ frustration – the application or the network – is important because knowing exactly where to look is the first step to solving slow response times. Here are four factors that affect network performance you might want to check when faced with network issues:

Latency: Think of latency as the speed limit on a highway. Traffic speed on a motorway is affected by many variables such as weather, other traffic, and highway signs. Likewise, data packets traversing a network are affected by many variables as well. The first step in mitigating latency is to break down the overall latency into that due to the network and that due to the application and its associated servers. With that determination made, visually graph both the application and network latency to help identify patterns and anomalies that deserve closer attention so that you can later drill down and figure out exactly what is causing the bottleneck.

Throughput: Throughput is the amount of traffic a network can carry at any one time. Like the analogy of traffic used to explain latency above, think of throughput as analogous to the number of lanes on a highway. The more lanes, the more traffic a highway can accommodate. When thinking of networks, the higher the bit rate, the faster files transfer. Slow response times might be an issue with your network not having enough throughput.

Packet Loss: Glitches, errors, or network overloading might result in the loss of data packets. Sometimes routers or switches might shed traffic intentionally to maintain overall network performance or to enforce a particular service level. In a well-tuned network intentional packet loss is hopefully a rare occurrence, though packet loss is still something that happens regularly due to a host of other reasons, and must be monitored closely to ensure overall network performance.

Retransmission: When packet loss does occur, those lost packets are retransmitted. This retransmission process can cause two delays; one from re-sending the data and the second delay resulting from waiting until the data is received in the correct order before forwarding it up the protocol stack.

These factors are not exclusive, but they do help paint a picture of the many things that can contribute to a slow network. Hopefully, armed with this information, you can start accurately diagnosing your network before performance issues arise.

Monitoring Virtual Networks – Real-Time vs. Post Capture Analysis

There has been much hype surrounding virtualized environments and it is safe to say that this technology is now out of the incubator and is a very real world solution to problems of scale.

As virtualization evolves, however, so do the challenges of maintaining security, cost-effectiveness, investment value, manageability, and compliance. Virtualized networks must still be accounted for and managed in much the same way that physical wired networks are managed – in fact, they are very similar from a network engineer’s perspective. Both require continuous monitoring, with the ability to dig in and troubleshoot potential issues at a moment’s notice. The difference lies in the way you choose to monitor your virtual network.

Real time analysis:
If you need to perform real-time analysis on a virtual network, the main thing to consider is buffer size. The nature of a virtualized environment means that there is a fixed amount of resources for many different applications to share. In essence, you are taking what was once a single computer and optimizing it for use with multiple applications. This allows for much greater efficiency since in most cases a typical application uses only a small fraction of the available hardware resources. Since the resources are now being shared much more efficiently, it becomes very important to set a buffer limit for network monitoring that is just enough to get the job done without compromising the execution of other applications on the virtual machine. It is also important to use the minimum number of captures possible to accomplish your network monitoring objective since each capture requires its own buffer, and consequently, your finite RAM.

Post Capture Analysis:
If you are doing post-capture analysis, your resource focus shifts from RAM to disc space. The goal in post-capture analysis is save all packets to static storage for analysis at a later time. This significantly reduces the need for buffering data in RAM for immediate analysis, but increases the need for disk space based on the overall throughput of the virtual network and the amount of time post-capture analysis is required. Assuming lower virtual network speeds of 100Mbps, you should generally allot the following disk space per time considered: 750 MB/min, 45 GB/Hr, 1.1 TB/day. Keep in mind, however, that post capture forensic searches are CPU and RAM intensive, so it is best to perform your analysis when other demands on the virtual machine are low, like at the end of the day or early in the morning. It’s also a good idea to pre-compute the maximum RAM your search will use. Ideally, you should already have some idea of what kind of data you’ll be wanting to inspect and will have search parameters in place that will pull up no more than 10% of your total captured data. Feel free to experiment and search, starting with a smaller set of analysis functions enabled until you’re sure you’ve found the data of interest.  Be judicious as to the types of searches you do and have an idea of what you expect your search results to look like before performing the actual search. This will save you time and resources.

Real-time analysis is best suited when you’re facing an immediate issue, like a report of poor application response time from the virtual server. Real-time analysis provides immediate interaction with the data, allowing you to expand and contract your analysis in real-time to zoom in on the issue. Post-capture analysis is best for long-term monitoring. While the virtual network is running smoothly at the moment, you never know when something may go wrong. If you’re constantly saving network history while performing on-going monitoring, even if only for a few hours, it will make the difference between knowing exactly what went wrong, or having to spend countless hours attempting to reproduce the issue or waiting for it to happen again.

With these considerations, you’ll be well on your way to overcoming blind spots and having complete visibility into your networks, whether they’re virtual or not.

OmniPeek – now enhanced for increased visibility into virtual networks with Net Optics’ Phantom Virtual Tap

Interop Las Vegas was a blast. Thanks to everyone who stopped by our booth. It was good to catch up with both customers and partners and meet the people that we work so hard for.

During Interop we announced the second installment of our premier network recorder, TimeLine 2. Our partners at Net Optics also had an announcement of their own during the well attended event – the integration of their Phantom Virtual Tap utility with WildPackets’ award winning OmniPeek network analyzer to provide organizations total visibility into both their physical and virtual network traffic.

This announcement comes at the heels of last week’s announcements of OmniPeek enhancements including Compass, a new interactive dashboard that provides real-time visibility into key network statistics over long periods of time with on-the-fly data retrieval and complete OmniPeek analysis.

The integration with Net Optics’ Phantom Virtual Tap addresses the lack of visibility into virtual networks spurred on by the increased shift to virtual environments. These virtual environments must still meet compliance requirements and be accountable by IT managers as if they were traditional networks. OmniPeek’s integration with Net Optics Phantom Virtual Tap offers this accountability, and more.

With the integration, OmniPeek now gives network engineers even more visibility into their networks and the ability to execute expert analysis on every part of their network including Ethernet, Gigabit, 10 Gigabit, 802.11a/b/g/n wireless, virtual networks, VoIP, and Video – all from a central management console.

We are happy to collaborate with Net Optics and look forward to keeping OmniPeek at the bleeding edge of network analysis.

Read the official press release here