Product Support
Product Activation FAQs
Downloads
Maintenance Programs
White Papers
WildPackets Forums
Technical Compendium
Additional Resources
Tip of the Month
Wireless Tips
Plugin Tips
Product Versions
Networking Books
Networking Glossary
Networking Links
Tech Support Requests
Home > Support > Additional Resources > Tip of the Month

Tip of the Month

Network Analysis Tip of the Month – April 2006


What If???

By Jeff Trawick, WildPackets Professional Services

In the February Tip, we described how some simple settings on the analyzer provide a great way to simulate networks, enabling you to model how traffic from one network would behave on another network of differing bandwidth. This month, we’re going to extend this discussion. An age-old question among network architects is “What if…?” “What if I add 25 more users for the database application?” “What if I my developers modify the communications behavior of our custom programs?” “What if I increased the bandwidth for my remote sites?” These and many other “what if” questions need answers if we have to design and implement networks that perform as expected and required. WildPackets Peek analyzer products are ready to help you these questions via our “What If” feature in the Visual Expert.

The best way to demonstrate this awesome capability is to walk through an example. Let’s assume that we want to determine how a web-based application would be affected if we added more users or changed the bandwidth of the links to the web servers. We’ll start by capturing and saving sample transactions from the application in its existing environment. Then we need to take the following steps to prepare for our “what if” analysis.

  1. Go to the Expert tab and select a single conversation that represents the transaction you wish to model.
  2. Right click on the target conversation and select the Visual Expert.
  3. In the Visual Expert, select the What If tab. This should result in a view that looks something like this:

The fields in the upper third of the screen are communications parameters that you can alter to simulate network conditions. The lower two-thirds of the screen shows the performance statistics for both the client and the server on standard bandwidth links, ranging from 32 Kbps to 1 Gbps.

You can model circuit conditions, such as latency or contention time. You can also model the results of altering the average size of the packets that are sent and received. Combined with the packets per transaction field and the packet send-to-receive ratio field, these features allow you to understand how each variable impacts the efficiency of network communications. All you have to do is enter representative values for each parameter and observe the resulting statistics for your target bandwidth. You will be able to immediately determine when a circuit with the specified bandwidth will become saturated.

This capability is especially useful in WAN environments, where bandwidth is more limited and costly. Since the inadequate performance of many WAN-based applications is due to the effects of latency – not bandwidth – the What If feature can allow you to demonstrate that more bandwidth is not always the answer. In many cases, applications need to be tuned to become more efficient by being more “network-friendly.” The What If tab can provide you with hard evidence to isolate the factors that contribute to unsatisfactory performance.

As another example, suppose you intend to deploy a new web-based application that you are testing in your lab. You are able to capture sample transactions, and you want to determine if your network environment can handle 50 users concurrently performing the same types of transactions. Set the network parameters to match your production environment and then change the number of simultaneous users to calculate the effects. For example, if you have a 100 Mbps network, look at the client and server lines for 100,000,000 bps and consider whether or not the calculated utilization will work in your network. Don’t forget about the other traffic already present on that network. You can easily see how big your data pipe needs to be to handle the anticipated load.

So give it try! Start by changing one parameter at a time and watch the results. You’ll soon be able to accurately model the impact of new apps, new users, or changing network conditions. You’ll no longer have to wonder “what if?...”!!!

Click on thumbnail for larger view
screenshot
Download a demo of OmniPeek
Custom Integration & Engineering
WildPackets understands that one size does not fit all. Moreover, we all face new challenges every day. WildPackets Custom Engineering performs software development and systems integration, complementing WildPackets products and enhancing the capabilities of Network Operations Centers.
Learn more...

Network Analysis & Consulting
WildPackets offers a full spectrum of professional services, available remote and on-site. Our network engineers provide expertise for your network troubleshooting, capacity planning, or baseline performance analysis needs.
Learn more...

Tip of the Month
Don’t Lose The Tags
WildPackets’ Technical Support Team regularly receives questions about capturing VLAN (Virtual LAN) tags in packets. Some customers report that they cannot see VLAN tags when capturing packets from their switches. The tags are usually missing because the capture configuration or the location of OmniPeek (or Omni Engine) is incorrect. So, this tip is aimed at understanding VLAN tags and how they can be captured using OmniPeek Product Family.