1419configuring custom applications

Copyright © 2003 OPNET Technologies, Inc. Confidential, not for distribution to third parties.

Advanced Application Models — Configuring Custom Applications

Session 1419

Application and Server Performance

Copyright © 2003 OPNET Technologies, Inc. Confidential, not for distribution to third parties. 2

1419 Advanced Application Models — Configuring Custom Applications

Agenda Custom application overview Custom application workflow Breaking down an application into tasks and phases Task configuration Lab 1: modeling a 3-tier e-commerce application

Task scheduling Connection reuse Lab 2: demonstrate connection reuse

Using backend custom application Lab 3: demonstrate backend CA

Miscellaneous: custom application over IP multicast, ACE… Troubleshooting Lab 4: troubleshoot misconfigurations



Why Model Applications?

Application behavior is what the end-users see Infrastructure, deployment is transparent to the users Better applications Better user satisfaction Better business

VS

This company’s website is fast!!!

This company’s website is lousy!!



Why This Session?

It is important to model applications as accurately as possible

In OPNET Standard applications

Predefined application behavior like request/response characteristics, scheduling, etc.

Model typical behavior of the commonly seen day-to-day apps HTTP, Email, Rlogin, Telnet, Voice, Video, Database

Custom applications Model specific behavior User has control to define the behavior of the application Can configure request/responses, scheduling, connections, etc Flexible, powerful, and generic

We discuss Custom Application !



Applications

Client-server applications

Examples: HTTP, FTP

Peer-peer applications

Examples: voice, video

Multi-tier applications

Examples: web-based applications, e-commerce, home-grown applications

REQUEST

RESPONSE

RESPONSE

3

RESPONSE

4

REQUEST

1

REQUEST

2

REQUEST

RESPONSE

REQUESTRESPON

SE



Multi-tier Applications

Functionality is divided into separate tiers or levels A single successful instance of the application consists of multiple

transactions A transaction consists of exchanges (request/response sequences) at the

same logical level Tiers can be located on the same computer or on separate computers.

RESPONSE

REQUEST

REQUEST

RESPONSE

Tier-1 transaction

Tier-2 transaction

Tier-3 transaction

RESPONSE



Custom Application

Can be used to model client-server, peer-peer, multi-tier applications Business: E-commerce, Medical Imaging, etc. Enterprise: ERP, CRM, etc. Defense: Command control, Recon data collection, etc. Home-grown



OPNET Application Architecture

P h asesD e fine com m u n ica tio n p a tte rns w ith in ea ch ta sk

T asksD e sc rib e b as ic un it o f u se r ac tiv ity

A p plica tio nsD e fine a pp lica tio n co n fig u ra tion

P ro filesD e scrib e use r b e h av io ur

Custom application



Profiles

Profile = collection of applications Describes activity patterns of

An individual user A group of users

Engineer

CEOCFO

Engineer

Engineer

Help desk

Marketing department



Profile Definition



Applications in Profiles

I have the definitions of the following applications:• Database Access (Light)• Email (Light)• Web Browsing (Light)• FTP

defined in



Custom Application Definition



Agenda Custom application overview Custom application workflow Breaking down an application into tasks and phases Task configuration Lab 1: modeling 3-tier e-commerce application


Using back-end custom application Lab 3: demonstrate backend CA

Miscellaneous: custom app over IP multicast, ACE… Troubleshooting Lab 4: troubleshoot misconfigurations



Configuring Standard Application Models: Workflow

Configure applications

Define profiles

Configure servers/peers

Deploy Profiles



Configuring Custom Application: Workflow

Define Profiles

Configure tiers

Deploy profiles

Configure tasks

Covered more in 1418

Configure custom app

Break down the application





Using custom application Lab 3: demonstrate backend CA




Breakdown of the Application

1. Identify the tiersFor example, an online e-commerce application might involve

Client Web server Authentication server Database server



PURCHASE LOGOUTLOGIN

CUSTOM APPLICATION

Breakdown of the Application (cont.)

2. Identify the independent tasks involved that make up a successful instance of the application For example, buying a book online = login + purchase + logout




3. In each task, identify separate actions that accomplish the tasklogin = connect + authenticate + reply

LOGIN

CONNECT AUTHENTICATE REPLY


CUSTOM APPLICATION



Breakdown of the Application (cont.)4. Break each phase into a sequence of requests/responses and

decide on the request/response pattern (between tiers identified in step 1)

authenticate = 1 request + 1 pkt/request + 1 KB/pkt + 1 response + 1pkt/response + 0.5 KB/pkt

LOGIN

CONNECT AUTHENTICATE LOGOUT


CUSTOM APPLICATION

Request Response




5. Decide on the parameters of the request/response packets, inter-request time, inter-response time, timeout properties in each phase, etc.

Phase

Request Response

Initialization time / think time

Inter-request time

Response Inter-packet time




Define Profiles

Configure Servers/Peers

Deploy profiles



Configure tasks





Using custom application Lab 3: demonstrate backend CA




Task Configuration



Task Configuration: Task Definition Object



Phase Configuration

Manual ConfigurationORACE



Task Configuration: Manual Task Attributes

Phase Name + Statistical Group Name Start Phase After (Specifies dependency) Source (Symbolic) Destination (Symbolic) Source->Dest Traffic Dest->Source Traffic REQ/RESP Pattern End Phase When (Specifies dependency) Timeout Properties Transport Connection (TCP/UDP)



Identifies the Phase Identifies the statistics for the Phase

Task Configuration: Phase Name



Task Configuration: Start Phase After

The starting time of a phase can be specified in 3 different ways Independent (the source does not depend on the completion of another phase, so

the ‘start phase after’ is set to ‘Application Starts’) ‘Previous Phase Ends’ (sequential phase execution) Some specific phase ends (provide valid ‘Phase Name’ after which this phase

starts)



Task Configuration: Source This attribute specifies the symbolic name of the node that acts as a source

for the corresponding phase

3 Special values (no extra symbol resolution needed): Originating Source

The phase starts on the node that supports the profile containing this custom application

Previous Source The node that was the source of the previous phase acts as the source

Previous Destination The previous phase’s destination acts as the source for this phase



This attribute specifies the symbolic name of the node that acts as a destination for the corresponding phase

4 Special values (no extra symbol resolution needed): Originating Source Previous Source Previous Destination Not Applicable – for processing phases

Task Configuration: Destination



Task Configuration: Source->Dest Traffic Initialization Time

Time spent in the beginning of the phase, before any packets are sent out

If no requests are sent, then this is a processing phase

Requests Responses

TASK

Phase 2Phase 1



Task Configuration: Dest->Source Traffic Inter-response Time

Explicit time that server will spend for each response packet

Computed at server: set to ‘Use Server CPU’

Request

Response

Phase



This attribute accomplishes the scheduling of request response sequences Serial : next request is not sent out until response for previous request

arrives

Concurrent : requests are sent out independent of arriving responses

Task Configuration: REQ/RESP Pattern

Phase

time

Request

Response

Inter-request time

Phase

time

Request

Response

Inter-request time



Task Configuration: End Phase WhenEnd Phase When …

Final Request Leaves Source (phase ends at ‘a’ in the figure) Final Request Arrives at Destination (phase ends at ‘b’ in the figure) Final Response Leaves Destination (phase ends at ‘c’ in the figure) Final Response Arrives at Source (phase ends at ‘d’ in the figure)

Source Destination

Response

Request

ab

c

d



Task Configuration: Timeout PropertiesTimeout Properties

Sets time limit on phase duration—phase completes after T seconds, whether or not all transactions are complete within the phase

Useful for recovery from lost packets/aborted connections After timeout, execute either next phase or next task

Source Destination

Response

Request

T sec



Task Configuration: Other Task AttributesTransport Connection (TCP/UDP)

Each phase can use either TCP/UDP/FC as transport protocol Connections can only be reused for TCP Each phase can open up to N connections, where N is the connection limit



Lab 1: Modeling Multi-tier Application The application we are want to model is a multi-tier e-commerce application.

A user (in Los Angeles) is trying to buy a book online from a retailer (in Seattle). The retailer’s front-end server interacts with a couple of other servers located elsewhere (authentication server in San Francisco and database server in Phoenix).



Lab 1: Modeling Multi-tier Application (cont.) First identify the tiers

Client Web Server Authentication Server Inventory Server

Identify the tasks involved Login Purchase Logout



Lab 1: Modeling Multi-tier Application (cont.) Split the tasks into phases

Login Connect Authenticate Reply

Purchase Surf Select Checkout Update customer database Update inventory Confirm checkout

Logout Disconnect



Lab 1: Modeling Multi-tier Application (cont.)

Model the request/response details in each phase

Client Web Server Authentication Server

1024 bytesDelay: 3 seconds Response Time :

0.8 seconds

Time

Delay: 1 second

1024 bytes

512 bytes

512 bytes

Database Server

Task Response Time > 2 + 3 + 0.8 + 1 = 6.8 sec

Init time: 2 seconds

Task: Login

Phase ‘Connect’

Phase ‘Reply’

Phase ‘Authenticate’



Task Response Time > 25*9 + 3 + 5 + 0.5 + 1 + 0.5 + 1 = 236 sec

Phase ‘Select’


ClientWeb Server

Authentication Server

Response Time for each response: 3 seconds

Time

Task: Purchase

Database Server

10 requests + 10 responses

Inter-req time: 25 seconds

init time: 5 sec

init time:0.5 sec

init time: 0.5 sec

Response Time 1sec

2048 bytes

3072 bytes

5120 bytes

5120 bytes

1024 bytes

1024 bytes

1024 bytes512 bytes

Phase ‘Surf’

Phase ‘Checkout’ Phase ‘Transaction_cust’

Phase ‘Transaction_inv’

Phase ‘Checkout_confirm

Request size: 5120 bytes

Response size: 51200 bytes




Client Web Server Authentication Server

1024 bytes

Time

Response Time : 2 seconds512 bytes

Database Server

Task Response Time > 2 secTask: Logout

Phase ‘Disconnect’




Total time taken by a single instance of custom application = Time to ‘Login’ + Time to ‘Purchase’ + Time to ‘Logout’> 6.8 + 236 + 2 sec= 244.8 sec

We expect the total time of the application to be at least 244.8 sec



Break




Configure tasks

Define Profiles

Configure tiers

Deploy profiles





Custom App Configuration



Configure Custom App: Task Scheduling



Configure Custom App: Task Scheduling (cont.)Three ways to schedule tasks

Serial (Ordered) All tasks are executed in the order specified in the task list of ‘Task

Description’ attribute

TASK 2 TASK 3TASK 1

Phase 1.1

Phase 1.2

Phase1.3Phase2.1

Phase2.2

Phase3.1

CUSTOM APPLICATION

time



Concurrent All the tasks start simultaneously, as soon as the application starts

TASK 2

TASK 3

TASK 1

Phase 1.1

Phase 1.2

Phase1.3

Phase2.1

Phase2.2

Phase3.1

CUSTOM APPLICATION

time

Configure Custom App: Task Scheduling (cont.)



Serial (Random) The tasks are executed one after another but in a random order The exact number of tasks can be specified in the ‘Number of Used

Tasks’ field

TASK 2TASK 3TASK 1

Phase 1.1

Phase 1.2

Phase1.3Phase2.1

Phase2.2

Phase3.1

CUSTOM APPLICATION

time

Configure Custom App: Task Scheduling (cont.)



Configure Custom App: Connections

New connection per request

Phase1

time

RequestResponse

Phase2

TASK



Reuse connections across requests

Phase1

time

RequestResponse

Phase2

TASK

Configure Custom App: Connections (cont.)



Reuse connections across phases

time

Request Response

Phase1

Phase2

TASK1

Phase1

Phase2

TASK2 CUSTOM APPLICATION




Reuse connection across tasks Request Response

Phase1

Phase2

TASK1

Phase2

TASK2

CUSTOM APPLICATION

Phase1




Hierarchy of attributes that decides connection reuse policy (in decreasing order of priority)

1. Task Config Object / Manual Configuration / Transport Connection / Policy

If set to ‘new connection per request,’ the next two attributes are ignored Otherwise, connections are used as determined by the policies below

Configure Custom App: Connection Management



2. Task Config Object / Manual Configuration / Transport Connections / Connections / Policy

Specifies if connections can be ‘reused across phases’ or if they should be ‘refreshed after phase’

Configure Custom App: Connection Management (cont.)



3. Task Config Object / Connection Policy Specifies if connections can be ‘reused across tasks’ or if they should

be ‘refreshed after each task’

Configure Custom App: Connection Management (cont.)



Objective: make all traffic between each pair of tiers reuse the same connection

Refer to the lab manual

Lab 2: Demonstrate Connection Reuse




Configure tasks

Define Profiles


Deploy profiles

Configure tiers

Break-down the application



Configure Tiers



Configure Tiers (cont.)

Assign TPAL addresses to the nodes Appears as attribute “Client Address” on workstations “Server Address”of servers “LAN Server Name” on LAN objects

Resolve Destination Preferences Destination Preferences

Resolve symbolic destinations to real destinations Specify a choice of destinations with a selection weight



Destination Preferences

Resolves symbol WEB_SERVER to web_server_1 & web_server_2

Resolves symbol DB_SERVER to db_server_1 & db_server_2



Destination Preferences Attribute



Symbol Resolution is done every time a Task is executed

Once a symbolic name is resolved to a node, the resolution will not change during the execution of the Task

If a symbolic name cannot be resolved, custom application logs an error and stops the task execution

Symbol Resolution



Contention Modeling

Server Contention Modeled for Src Dest Traffic: Init Time Dest Src Traffic: Request Processing Time

If Server_Job_Name attribute is set, contention will be modeled using Advanced Server / Mainframe Models Refer to the Online Documentation on Advanced Server Configuration for

details on modeling Advanced Server / Mainframe jobs

Otherwise, the Simple CPU model will be used for contention modeling Refer to FAQ 1106 for details on configuring the Simple CPU model



Source Preferences

Independent sources Set the “Start Phase After” to “Application Starts”

Soldier 1

Soldier 2

Soldier 3

Commander HQ



Source Preferences (cont.) Identify the nodes that act as the source of any of the phases Specify the source preferences on each node so that the symbol in the source

preferences is the same as the symbol of the phase ‘Source’ that this node supports



Available Statistics



Standard two-tiered applications (Email, FTP, Http, etc.) trigger execution of custom application from the server

Each application request triggers the start of the custom application on the server with a given probability. Once the custom application run is over, a response is sent back to the client.

Back-end Custom Application

Custom

Back-endREQUEST

RESPONSE

1

3

2



Back-end Custom Application (cont.)

Specific advantages Integration of regular and custom applicationsApplication-specific statistics Improved modeling of complex web applications, web

caching, email, etc.



Back-end Custom Application—Attributes



Agenda Custom Application Overview Custom Application Workflow Breaking-down an application into tasks and phases Task Configuration lab 1: Modeling 3-Tier E-Commerce Application

Task Scheduling Connection reuse Lab 2: Demonstrate connection reuse

Using back-end custom application lab 3: Demonstrate backend CA

Miscellaneous: Custom app over IP Multicast, ACE… Troubleshooting lab 4: Troubleshoot misconfigurations



Lab 3: Back-end Custom ApplicationRefer to the lab manual



IP Multicast / ACECustom applications can run over IP Multicast

Simply set the Phase Destination to the IP Multicast address Supported over UDP only Supports only Src Dest Traffic Refer session 1316 for IP Multicast configuration

Integration with ACE Can import an ACE trace file Custom application will use the trace file to “play-back” the same behavior The “play-back” is at the task level Refer session 1209 for ACE



Agenda Custom application overview Breaking down an application into tasks and phases Custom application workflow Task configuration Lab 1: modeling 3-tier e-commerce application


Using custom application to model back-end behavior of servers Lab 3: demonstrate backend CA




Troubleshooting Guidelines

1. Check simulation logs2. Look at the “Common problems” section of this presentation3. Use constant distributions to make application deterministic4. Use detailed Custom Application Statistics (phase, task…)5. Collect application Traffic Sent/Received stats in “All Values” mode

Shows exact size and time data was sent 6. Make sure this is not a network issue

Connect an application demand between your client and server See if you get application demand response time statistics

7. Scale down your network Isolate the problem

8. Use “User Defined Reports” in “Scenarios” menu Globally visualize attribute settings

9. Use “Network Difference Report” in “Scenarios” menu Compare a similar working scenario



Troubleshooting: Simulation Logs

Simulation = first place to lookAvailable in DES menu



Troubleshooting: Simulation Logs—Profile

“Engineer” profile

“FTP” application “HTTP” application

Simulation


Simulation


Profile won’t repeat if profile duration is equal to simulation duration

In serial mode, an application will not start if previous application duration is equal to profile duration



Troubleshooting: Simulation Logs—Profile (cont.) Profile set on a client doesn’t exist

Service set on server doesn’t exist


?

?“FTP (Light)” application

I’m an engineer

Sorry, I don’t know what an engineer is

I’m running “FTP

(Light)”

Sorry, I don’t know what “FTP (Light)” is



Troubleshooting: Simulation Logs— Standard Apps

All required application parameters are not configured

“FTP (Light)” is a FTP application

Sorry, I need more information to use “FTP (Light)”:

• File size

• Inter-request time

Service set on server doesn’t exist

?Profile

“engineer” uses “FTP (Light)”

Sorry, I don’t know what “FTP (Light)” is



Troubleshooting: Simulation Logs—Custom Apps

Source in phase is not resolved

Destination in phase is not resolved

?Task ‘login’ has ‘my_destination’

destination

Sorry, I don’t know who the real ‘my_destination’ is

?Task ‘login’ has ‘my_server’ as

source

Sorry, I don’t know who the real ‘my_destination’ is



Troubleshooting: Simulation Logs—Custom Apps (cont.)

Two or more phases with same name

Sorry, I am confused. There are two phases with the same name : ‘connect’

Unknown task in application specification

?s

online_shopping_app uses ‘purchase’

task

Sorry, I don’t know what “purchase” is.



Common Problems: Simulation Settings ‘Profile start time + application start time offset’ < ‘Convergence time of routing protocols

and spanning tree algorithm, etc.’

I want to send this FTP packet

Wait, I don’t have a route to the server yet

‘Profile start time + application start time offset’ > ‘Simulation end time’ Common when using exponential distribution with start time and/or start time offset


Simulation

“FTP” application

“Engineer” profileSimulation

Profile start time

Profile start time Application start time offset




Common Problems: Profile Settings If application duration is longer than profile duration, the application

will be terminated when the profile is over

The symbol map “Unlimited” for profile and application “Repeatability” has a default inter arrival time of 300 secs



Simulation





300 secs 300 secs 300 secs

Etc…



Common Problems: Custom App Settings If the traffic for a phase is configured beyond the application

duration, that phase is not completed. Also, other phases dependant on this one will not execute.

In a multi-tier application with phases A->B and B->C, the destination symbol C must be resolved on the node that is destination for phase A->B

TASK 2

Phase2.1

Phase2.2

APP

This phase

is not executed

Wait, I don’t know who C is!!!

A B ?



Common Problems: Custom App Settings (cont.) In the phase definitions, the first phase cannot use the special symbols

“previous source” and “previous destination” when specifying the source and destination

Phases are not executed if a prior phase which precedes these (in dependency) times out and the time-out action is ‘Go to next task’

Please be careful with the first phase!!!

APPPhase 1.1

TASK 2 TASK 3TASK 1Phase 1.2Phase1.3 Phase2.1

Phase2.2

Phase3.1

APP

Time up!! Going to TASK 3, Phase 2.2

not executed



Advanced Troubleshooting

Diagnostic traces For Custom application type: “ltrace gna_ca”

for task information: “ltrace gna_task” for connection information: “ltrace gna_conn” for traffic (requests/responses) information: “ltrace gna_traf

For all applications: “ltrace gna” Simple example

Start simulation under ODB ODB> ltrace gna_conn ODB> cont

This is an advanced technique. For more details, see session 1502 – “Debugging Simulation Models – Introduction”

Run OPNET debugger (ODB)



TS FAQs

729 How do I configure a back-end custom application?

769 What is the Task Weight attribute used for in custom applications?

986 Is IP Multicast supported for custom applications?

1160 I don’t see any application traffic or I don’t see the expected application traffic. How do I troubleshoot my application configuration?

1170 I have configured a custom application and it works fine with the simple CPU model. How do I integrate the custom app with advanced server model?



Agenda Custom application overview Breaking down an application into tasks and phases Custom application workflow Task configuration Lab 1: modeling 3-tier e-commerce application






lab 4: Troubleshooting

Objective Learn how to troubleshoot a custom application setup Refer to the lab manual



Take Away Points

Custom application workflow Breakdown of application Task configuration Symbol resolution

Advanced features Scheduling Connection reuse

Back-end custom applicationTroubleshooting



Related Sessions

Configuring Application Models — Session 1418 Trends in Traffic Modeling — Session 1338 Predicting Server Performance Scalability Intro — Session 1405 Introduction to Using ACE — Session 1209 Planning Application Deployments with ACE — Session 1409 Customizing Application Layer Models — Session 1509



Questions?



Thank You

1419configuring custom applications

Documents