Use Standardized, Artificial Traffic for Analysis

Analyzing real-life traffic, with all its variations and eccentricities, has its strong points. It gives you insight into what really happens with your users' actual performance. But it can also introduce unpredictable results because real life is exactly that -- unpredictable.

For example, the results of measuring an application's transaction response time vary with the size of transactions, whether any users have used the application recently, and so on.

You can avoid some of these issues by automatically generating uniform transactions at regular intervals (called synthetic transactions) and measuring results. PacketWise can, at your discretion, initiate synthetic web or other TCP transactions at periodic intervals to verify the availability of critical hosts as well as collect performance data.

Synthetic transactions are similar to scheduled pings or SNMP polls, but with these important advantages:

• PacketWise's detailed analyses of transaction behavior and response times apply to synthetic transactions, giving you the ability to profile network and host behavior over time. This information is much more helpful than knowing if a device simply responds to pings or not.
  
  
• When PacketWise sits at the network edge, polls are local, consume less bandwidth, and can therefore be more frequent and impose less network burden.
  
  
• Synthetic transactions can determine if a service or application is running, not just if a server is responding. They provide a more sophisticated assessment of application availability.
  
  
• Distributed PacketWise appliances can serve as local clearinghouses for availability information, forwarding situations of interest or concern to central locations via email, SNMP traps, or syslog messages. The need for long-distance polling by central management platforms is eliminated.

To choose this approach, follow the steps below:

   Steps:

1. To tell PacketWise to initiate web or other types of TCP transactions at periodic intervals, access the command-line interface (CLI) and enter the command synthetic add.
   
   Examine and choose carefully for the many parameters in the synthetic add command. For example, suppose you want to measure the performance of web transactions to one of your Intranet application servers. You determine that a transaction once every ten minutes is sufficient, giving you 144 occurrences each day to measure, average, and assess.
   
   For this example, you'd choose an interval of 10, ignore the repeat and id parameters, choose http, enter the domain name of the web application server, and finish with a forward slash and an html pathname on the server. Your command would end up looking like:
   
   synthetic add 10 "http://appserver.domainname.com/testfile.htm"
   
   Or, in another example, suppose you want to know if a host is there and responsive. You could choose a five-minute interval, echo, and enter the domain name of the host you're wanting to check, rendering:
   
   synthetic add 5 "echo://test.domain.com"
   
   
2. To analyze your synthetic transactions separately from other traffic, they must have their own traffic classes. Enter the CLI command synthetic options create-classes on to create distinct traffic classes. It's the default setting, but just in case anybody has changed the setting, it's best to make sure.
   
   Note: PacketWise creates one synthetic transaction class per host. If you create more than one synthetic transaction for a host, all transactions will get classified in a single class. For instance, suppose you create an echo transaction to test.com and an http transaction to test.com, PacketWise will create a single class, Localhost/test.com, and classify the echo and http transactions in this class.
   
   
3. Wait through a period of time that is at least a couple of your interval periods. Then check your Monitor screen.
   
   You should see a traffic class for your synthetic transactions with a child class for each of the hosts you included in your commands. Your host classes should list some class hits if sufficient time has passed to issue your synthetic transactions.
   
   
4. Enter the CLI command synthetic show. You'll see each of your synthetic transactions, and if any have completed, their results. For example, if you specified a synthetic transaction using echo, you can see if your device was responsive.
   
   If you decide you don't want one of your synthetic transactions, note its ID number from the output of of the synthetic show CLI command, and use that ID with the synthetic delete command.
   
   
5. Decide if you want a policy on your new traffic classes for your synthetic transactions.
   
   You would choose a policy if you are trying to match the performance of traffic in another traffic class. If you have a class that handles your real-life transactions that are similar to your synthetic transactions, then duplicate any policy you have on the real-life traffic class.
   
   For example, recall the earlier scenario to measure the performance of web transactions to a certain application server. Suppose that traffic's real transactions have a rate policy (with settings of 0 bps guaranteed, burstable at priority 5, no limit). In that case, you'd want to assign the same rate policy to the test transactions under your synthetic transactions' traffic class.
   
   You would not bother with a policy if you are simply wanting the transactions to go through, and you don't care about mimicking any other traffic's performance conditions. For example, recall the earlier scenario to test if a device was present and responsive. In this case, you'd probably skip a policy.
   
   If you decided a policy was appropriate, define and apply that policy. For instructions on creating each type of policy, choose a topic from the navigation bar in PacketGuide's Tasks->Policies page.
   
   
6. Let some time pass, at least a couple of days if you want a realistic quantity of data to analyze.
   
   
7. You can now apply any PacketWise analysis technique to your synthetic transactions' traffic classes. Analyze response times, check the monitor page, or create any graph you see on the list of available graphs.
   
   
8. If you wish, use the adaptive response feature to keep you posted if something of interest happens with your synthetic transactions.
   
   For example, recall the scenario testing web traffic. You might want to add an event based on the measurement variable web-response-4XX that would notify you if your web transaction failed (such as in a "404 - Not Found" error). Or perhaps a different event that looks at one of the service-level or response-time delay metrics and notifies you if response time dips below desired performance.
   
   For the other scenario, you might want to notify yourself if your device is unresponsive. Your event could use a measurement variable such as the tcp-conn-server-ignores, tcp-conn-server-refuses, or another measurement variable of your choosing.