This lab teaches the application performance of two different network architectures: daisy chain and collapsed backbone network. The lab shows a collapsed backbone data network in which there is a core switch in the basement equipment room. The core switch is linked directly to a workgroup switch on each floor. Another option is to link the switches in a daisy chain. In this approach, the basement core switch is linked directly to the first floor switch, the first floor switch is linked directly to the second floor switch, and so forth.
The lab shows the application latency introduced by connecting building switches in different ways. This lab also teaches to use OPNET's Application Characterization Environment (ACE) module to visualize, troubleshoot, and predict application performance.
Overview
The First Bank of Paradise's Operations building has 10 floors, each having multiple users connected to a workgroup switch in the floor's telecommunications closet. The users share an Oracle server and 6 file print and email servers in the basement.
In Scenario 1 the switches on each floor are daisy chained to the core switch in the basement. We will see that this daisy chain approach introduces high application latency to users on the highest floor.
In Scenario 2 the daisy chain topology is retained, but the core switch is moved to the fifth floor. We will see that this reduces latency on the highest floor but increases it on the bottom floor.
In Scenario 3 the core switch is kept in the basement, but a collapsed backbone topology is used, in which the core switch in the basement is linked directly to the workgroup switch on each floor.
Then we will analyze the performance of the Oracle application using ACE module. We will investigate the bottlenecks, which lead to unacceptable response times. 2
Lab instructions
Step 1: Open Lab 2
[1] Download the file Lab3.zip from the course webpage and unpack it to your model directory (usually, C:\Documents and Settings\User\op_models).
[2] Start IT Guru.
[3] Select File => Open…
[4] Scroll down to the project named MultiStory_Building_LAN, select it and click OK.
[5] Select File=> Save as
Name the project
XX_ MultiStory_Building_LAN
XX: is your lastname+your id
Several users are connected to a switch on each of the 10 floors. The users share an Oracle server and 6 file print and email servers in the basement.
Subnet : A subnet is a container used to create hierarchy of network levels. Double-click on the subnet named "6 File Print & Email Servers" to enter it. Here, we can see the servers clustered together. Right-click in the workspace and select Go To Parent Subnet to go to the upper level.
Also the LAN icon represents several workstations connected in a switched LAN. The number of workstations can be set by editing its attributes.
The users on different floors are running a 2-Tier Oracle (client/server) application. We will study the performance of this application.
Step 2: Configure and run simulation
Evaluate the network performance for a busy hour of the day.
[1] Click on the configure/run simulation toolbar button.
[2] Make sure the simulation Duration is set to 1 hour.
[3] Click Run.
[4] When the simulation completes, click Close.
Step 3: View results
View the Oracle application response time for users on the floors 1, 5, and 10.
[1] Right-click on the 95 Users Floor 10 object and select View Results.
[2] Expand Requesting Client Custom Application and select Application Response Time (sec).
[3] Select Show. This is the graph for the Oracle application response time which will be discussed later so do not close the graph window.
[4] Click Close in the View Results window.
[5] Right-click on the 50 Users Floor 5 object and select View Results.
[6] Choose Requesting Client Custom Application => Application Response Time (sec).
[7] Click Add and then click on the graph panel for the first graph you created. This is done to display statistics for users on different floors on the same panel.
[8] Repeat the steps from 5 to 7 to add the application response time for users on the floor 1 to the same graph.
Note: To toggle the graphs on and off, use the hide or show all graphs button.
Now we have the statistics for users on the floors 1, 5, and 10 on the same graph.
Your results should be similar to the graph above.
• As we can see, the application response time is close to 6 seconds for users on the floor 10.
• It reduces as we move to the lower floors. Users on the floor 1 have the smallest response time. This shows the amount of latency introduced by the switches.
Users on the top floor report high application response times. So the company decides to reduce the number of hops for the users on upper floors by moving the core switch and the servers to the fifth floor.
Step 4: Switch to next scenario
[1] Select Scenarios => Switch To Scenario => Daisy_Chain_Network_Server_On_Fifth_Floor.
The company restructures the network at no additional hardware cost to achieve better application performance for users on upper floors. 6
Step 5: Configure and run the simulation
Rerun the simulation for a busy hour of the day to see if the users on the floor 10 get better response times as intended. Refer to previous steps for setting the duration and running the simulation.
Step 6: Compare results
Let us compare the application response times for users on different floors. We expect that restructuring the network should reduce the application response times for users on upper floors.
[1] Right-click on 95 Users Floor 10 and select Compare Results.
[2] Choose Requesting Client Custom Application => Application Response Time (sec).
[3] Click Show and then click Close in the View Results window.
[4] Repeat same steps for 50 Users Floor 5 and 70 Users Floor 1.
Your results should be similar to the graphs below.
• As expected, the Oracle application response time went down for users on the floors 5 and 10.
• But the users on the floor 1 suffered an increase in response time.
The company decides to change the architecture from a daisy chain to a collapsed backbone network hoping to achieve the same application performance for all the users. 7 8
Step 7: Switch to next scenario
[1] Select Scenarios => Switch To Scenario => Collapsed_Backbone_Network.
Step 8: Configure and run the simulation
Rerun the simulation for a busy hour of the day to evaluate the network performance. Refer to previous steps for setting the duration and running the simulation.
Step 9: Compare results
Let us compare the Oracle application response times for all 3 scenarios. This will give us a clear picture of the best architecture for this kind of a network. Follow the same instructions as in Step 6 to get the graphs.
Your results should be similar to the graphs below.
Now the Oracle application response time decreased for users on all floors. However, even these new values are too high for our small network. Thus, to find the origin of the high response times we should analyze the performance of the Oracle application itself. 10 11
Step 10: Application Characterization Environment
The end-to-end performance of networked applications depends on complex interactions among applications, servers, and networks. IT organizations need a detailed, quantitative understanding of these dynamics to efficiently and cost effectively deploy applications and troubleshoot problems. OPNET's Application Characterization Environment (ACE) directly addresses these challenges with an embedded expert knowledge about how applications, networks, and servers operate. ACE can be used in a pre- and post-deployment environment to:
• visualize, diagnose, and perform high-level predictive analysis of an application's performance;
• quickly identify and pinpoint individual components of application and network delay in an application, thus allowing to focus and apply appropriate resources on those issues that have the biggest impact on performance.
The ACE module requires ACE traffic data files (filename.atc.m) called "trace files" or "capture files" as input. Trace files are simply a snapshot of the application traffic in your network. This traffic is in the form of packets generated by your applications. Assuming that the trace files were captured correctly, their traffic information would be more accurate that any user approximations of real-world traffic.
The ACE module analyzes your traffic data and present results in:
• reports, graphs, and tables;
• visualization of application behaviour;
• diagnosis of bottlenecks and performance problems;
• predictive analysis of same traffic on different network;
• a file that IT Guru can import to simulate your application's traffic (also known as trace-driven simulation).
The last option was used in this lab to simulate a 2-Tier Oracle application. Let us analyze the application in detail using ACE.
Note: The trace file Oracle_2_Tier_Application.atc.m was captured in another network, different from the simulated one. Thus, the subsequent ACE analysis provides qualitative results, rather than quantitative ones (since some parameters of the origin network don't correspond one-to-one with those of the simulated network).
Step 11: Open the Oracle application in ACE
[1] In the IT Guru window select File => Open…
[2] Select Application Characterization from the pull-down menu.
[3] Scroll down to the project named Oracle_2_Tier_Application, select it and click OK.
Step 12: Visualize the application
The Data Exchange Chart window appears. It is shown in the following figure. Analyze the application in detail using this chart.
The Data Exchange Chart shows the data transferred between tiers on a time line. The colors of the application messages represent the size of the messages. Each group colour represents a histogram of message sizes.
• The order of tiers can be changed to make the chart easier to interpret by dragging the tier name up or down. In this case, keep the tiers in the same order, with the Oracle_client tier on the top and the Oracle_server tier on the bottom.
• For each group, about one-third of the messages are yellow (101 to 500 Bytes per message), and about two-thirds are orange (1 to 100 Bytes per message). This shows that the application is sending many small messages.
• Differentiate the messages flowing in different directions. Select View => Split Groups.
• Now the messages are split into two groups and you can detect more details. The upper group represents messages from the client to the server and the lower group represents messages from the server to the client. It can be seen that in the client-to-server message group, about half of the messages are orange, while in the server-to-client message group, about two-thirds of the messages are orange.
• View the tooltip by resting the mouse over the first group of messages. The tooltip shows that the first message group represents 183 messages in each direction.
Step 13: Analyze with AppDoctor
[1] Select AppDoctor => Summary of Delays.
This option provides insight into the root cause of the overall application delay. It divides the total application response time into four components:
• Application delay is the total time it takes to process the application at each tier, including user think-time.
• Propagation delay is the component of delay due to latency in the network. (Latency is the time required for 1 bit to be transmitted across the network.
• Transmission delay is the component of delay caused by the limited bandwidth of the network.
• Protocol/Congestion delay is a metric of network restriction to packet flow. This restriction may be caused by packet queuing in the network (congestion) or by flow control mechanisms imposed by network protocols. TCP, for example, has several built-in flow control mechanisms.
[2] Rest your cursor on the red part of the bar chart to see the tooltip.
Notice that the largest contributing factor to the application response time is propagation delay. The Diagnosis function of AppDoctor should give us further insight into the cause of this delay.
Step 14: View AppDoctor's Diagnosis
AppDoctor's Diagnosis provides a more granular view of the potential bottlenecks affecting this transaction. Diagnosis tests the current transaction against issues that often cause performance problems in network-based applications, grouped by category. Values that cross a specified (user-settable) threshold are marked as bottlenecks or potential bottlenecks.
[1] In the Data Exchange Chart window select AppDoctor => Diagnosis.
[2] Examine the four bottlenecks: Protocol Overhead, Chattiness, Network Cost of Chattiness, and Propagation Delay (click on the word Bottleneck to see a description of the diagnosis in the bottom pane for each bottleneck).
[3] Close the AppDoctor Diagnosis window.
[4] In the Data Exchange Chart window disable the split groups view by selecting View => Split Groups.
Step 15: Investigate the data exchange
AppDoctor's Summary of Delays and Diagnosis have revealed issues with both the network and the data exchange between tiers. Now when you know more about the possible issues, the Data Exchange Chart might provide additional insight. Examine the beginning of the transaction (that is, the traffic between 6.1 and 6.3 seconds) more carefully.
[1] Zoom to the area of the chart that represents the 6.1-6.3 second time period as follows.
• Right-click in the empty workspace of the Data Exchange Chart.
• Select Zoom to Rectangle from the pop-up menu and then drag the cursor to create a box around the target area.
If you are not happy with your initial zoom, you can select Previous Zoom from the pop-up menu and try again. After you adjust the zoom level, you can use the arrow keys to scroll in all directions.
As you zoom into the Data Exchange Chart, the groups of messages resolve into the individual application messages.
[2] Study the individual messages. The arrowhead indicates the direction that a message flows.
[3] Notice that:
• the application is composed of many small messages (as indicated by the orange and yellow colors);
• it seems to repeat a simple request and response pattern. Each change of direction is called an application turn - the application changes the direction of data flow. Applications with high turn counts are generally considered chatty and are sensitive to network delay. The sensitivity occurs because each message must be received at a tier before the corresponding response is sent, and thus each message is affected by network latency.
[4] You conclude that the Data Exchange Chart visualization confirms the analysis predicted by Summary of Delays and Diagnosis: the application is chatty, and the chattiness means that network delay slows the application response time significantly.
Step 16: Predicting the application performance
AppDoctor's QuickPredict is an analytic simulation mechanism that enables you to test the performance of an application quickly under different network conditions. With QuickPredict you can test possible network upgrades to evaluate the impact they might have on application performance. Let us see how latency would affect the application performance.
[1] In the Data Exchange Chart window select AppDoctor => QuickPredict.
[2] Select Latency for X Axis and set the Min Latency to 0ms and the Max Latency to 20ms.
[3] Click on the Update Graph button.
This graph shows that the application response time is directly proportional to Latency. So, if this application is to be deployed on a WAN, it is very important to rewrite the application to have better response times. 18
Questions
[1] Let us upgrade the daisy chain network with the server in the basement from 10BaseT to 100BaseT and see if this will help us to decrease the Oracle application response times for users on different floors.
Switch to the scenario Daisy_Chain_Network_Server_In_Basement and duplicate it. Name the scenario as Daisy_Chain_Network_Server_In_Basement_100. Select the LANs on all floors and change their attributes to 100BaseT. This can be done as follows.
a) Right-click on any workgroup and choose Select Similar Nodes.
b) Right-click on the same workgroup again and select Edit Attributes.
c) Check the Apply Changes to Selected Objects option. Click in the Value column for model and choose 100BaseT_LAN. Click OK and save the project.
Perform the same actions with the links and set them as 100BaseT.
Since the switches and servers support 100BaseT, there is no need to replace them.
Run the simulation and create a graph that compares the Oracle application response times for users on the floors 1, 5, and 10.
Explain the graph and comment on the results.
[2] Now we are going to examine AppDoctor's QuickPredict in predicting the application performance. QuickPredict allows us to estimate the impact of bandwidth on overall application response time. However, we need to know latency, which is one-half of the total round trip time.
a) Switch to the scenario Daisy_Chain_Network_Server_In_Basement.
b) Right-click anywhere in the project workspace (but not on one of the nodes or links) and select Choose Individual Statistics from the pop-up menu. Choose Node Statistics => LAN => Delay (sec). LAN Delay lists the queuing delay, transmission delay, and total delay for each LAN on the network.
c) Click OK and save the project.
d) Run the simulation and create a graph that compares the LAN delays for the floors 1, 5, and 10. The resulting graph should resemble the one below.
Although there are significant delay variations for LANs on the floors 1 and 5, we approximate them as 0.5 and 1.0 ms correspondingly. For the floor 10 we approximate LAN delay as 1.6 ms.
e) Open the Oracle application (Oracle_2_Tier_Application) in ACE and in the Data Exchange Chart window select AppDoctor => QuickPredict.
f) Select Bandwidth for X Axis and set the Min Bandwidth to 10BaseT (10 MB) and the Max Bandwidth to 10BaseT (10 MB) (as long we are interested only in certain values, not a continuous function).
g) Set the value of Latency as 0.5ms (delay for users on the first floor) and click on the Update Graph button. Repeat this step with two other values corresponding to users on the fifth and tenth floors. Compare the obtained values with the measured ones on the Step 3. Do they match?
Switch to the scenario Daisy_Chain_Network_Server_In_Basement_100 and perform the same steps. The resulting graph should resemble the one below.
Now we approximate LAN delays for the floors 1, 5, and 10 as 0.06, 0.11, and 0.18 ms correspondingly. Do not forget to select 100BaseT (100 MB) as the Min Bandwidth and Max Bandwidth in the QuickPredict Control window.
Combine simulation results and predicted values in a table as shown below.
Comment on the obtained results.
Simulated (Predicted) values of the Oracle response time, sec
Floor 1
Floor 5
Floor 10
10BaseT
x.x (y.y)
100BaseT
