Test Case: Maximum DPI Capacity and Performance with Multiplay Traffic
4. TCP parameters are important when optimizing the test tool. Refer to the Test Variables section in Table 1 to set the correct TCP parameters
There are several other parameters that can be changed. Leave them at their defaults values unless you need to modify them for testing requirements.
For a step-by-step workflow, see Appendix B.
Figure 114. TCP Buffer Settings
5. Configure the AppReplay Initiator and AppReplay Responder activities. Add the AppReplay Peer Activity to both the client and server NetTraffic.
Figure 115. IxLoad scenario editor view with Client/Server NetTraffics and AppReplay Peer Activities
a. Refer to the Test Variables section above to configure the AppReplay Initiator parameters.
The AppReplay Activity can be used to replay application flows using captured packets. The application flows are then replayed statefully. This accommodates devices that require stateful message handshakes in order to operate properly.
AppReplay leverages IxLoad's powerful infrastructure to provide massive scalability and performance.
b. Add a Custom Flow for each application type.
i. Add a Custom Flow – TCP command for each Application Flow type.
ii. Specify the Destination as the AppReplay Peer Activity configured on the
v. If there are multiple flows within the capture file you can use the Follow First SYN or the User defined Filter options to isolate the flow that you want to replay.
vi. Follow the 5 steps above to create Custom Flows that represent Streaming Media, Yahoo Messenger, Email and BitTorrent.
Figure 116. AppReplay peer activity command settings
c. In the Advanced Options tab define the Maximum Concurrent Flow(s) per user as 5, so that all 5 flows will be replayed in parallel, for each subscriber. Also enable Verify Length as the Payload Verification Option for maximum performance.
Figure 117. AppReplay peer activity advanced options
d. The responder AppReplay peer Activity on the server side will be automatically configured based on the client side initiator settings. Only the Payload Verification Option needs to be set as Verify Length for maximum performance.
6. Having setup the client and server networks and the traffic profile, the test objective can now be configured.
Open the Timeline and Objectives view. Select the test Objective Type to be Initiator Peer Count and Objective Value to be 120,000. The Initiator Peer Count objective is chosen in order to activate all the subscribers and all 5 custom flows per user – 120K subscribers multiplied by 5 connections per subscriber equals 600K concurrent connections/flows.
The following should be configured:
Figure 118. Test objective settings
For a step-by-step workflow, see Appendix E.
7. Run the test for few minutes to allow the performance to reach a steady-state. Steady state is referred as Sustain duration in the test. Continue to monitor the DUT for the target rate and any failure/error counters. See the Results Analysis section below for important statistics and diagnostics information.
Interpretation of result statistics can sometimes be difficult, deducing what they mean under different circumstance. The Results Analysis section below provides a diagnostics-based approach to highlight some common scenarios, the statistics being reported, and how to interpret them.
8. Iterate through the test varying the number of subscribers, the numbers of connections per subscriber and size of the transaction to determine the steady state capacity of the DUT.
a. The test tool can be started and stopped in the middle of a test cycle, or wait for it to be gracefully stopped using the test controls shown here.
For a step-by-step workflow, see Appendix F.
Results Analysis
To analyze forwarding performance and determine the maximum capacity it is necessary to examine multiple test iterations, comparing the results for all test parameter variations, including:
Number of IP addresses or subscribers
Number of concurrent flows/connections per subscriber
Different application flows and size/duration of the flows
Table 65 lists the key performance statistics that must be monitored. These statistics help determine if the device has reached its saturation point and to identify any issues. Interpreting the results in the correct manner will also ensure that transient network, device or test tool behavior does not create a false positive condition.
Table 65. Key AppReplay performance statistics to monitor
Metric Key Performance Indicators Statistics View
Performance metrics Connections/sec, total connections, number of simulated users, error. Per-flow statistics if advanced stats option is enabled
AppReplay – Flows
AppReplay – Per Flow Stats Initiator
Real-Time Statistics
Error! Reference source not found. provides a real-time view of the measured performance or a test run. The Concurrent Connection statistic shows that the DUT is able to sustain approximately 600K concurrent flows/connections. 120K Initiator Peers were emulated, which is equivalent to subscribers, ensuring all the IP configured addresses were utilized.
Figure 119. AppReplay objective statistics
The following figure is the real-time view of the AppReplay Throughput, which is equivalent to the good put of the DUT.
Figure 120. AppRepaly Throughput (Goodput) Statistics View
The throughput can be viewed by reviewing the L2-3 Stats, this indicates the device’s forwarding performance that was sustained.
Figure 121. Layer 2-3 Statistics
AppReplay flow statistics provide an insight with application granularity. To view the per-flow statistics, the Enable Advanced Stats option should be enabled in the AppReplay
Advanced Options dialogue before the test starts.
Figure 122. AppRepaly Peer Activity Advanced Options
The AppReplay per flow statistics view can be used to analyze the number of flows initiated and succeeded, number of bytes transmitted and received, errors, and latency measurements on per flow basis.
Figure 123. AppReplay per flow statistics view
Troubleshooting and Diagnostics
Table 66. Troubleshooting and diagnostics Issue Diagnosis, Suggestions
What are the optimal statistics that can be used to certify that the optimal capacity
The relatively quick way to know if the device is at maximum capacity is to incrementally add new test ports, and see if the overall concurrent connections, connections per second and throughput metrics increase.