Use Standardized, Artificial Traffic for Analysis
Instructions to automate synthetic transactions and collect data about
them 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
- 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:
- 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
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 or IP address of the web application server, and finish with a forward
slash and an html pathname on the server. Your command would end up
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 or IP address of the host you're wanting to check, rendering:
synthetic add 5 "echo://test.domain.com"
- 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.
- 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.
- 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
- Decide if you want a policy on your new traffic classes for your synthetic
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'
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
- Let some time pass, at least a couple of days if you want a realistic
quantity of data to analyze.
- 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
- 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
or another measurement
variable of your choosing.