How do I generate traffic using the custom application model?

How do I generate traffic using the custom application model?

If you do not see expected results using the custom application, read the following list to identify common configuration problems, typically due to network or server behavior. Descriptions of the problems and their solutions appear below the Problems list.

Typical Problems:
 

1. No traffic is flowing out of a workstation or LAN.
2. Not all applications or tasks are executing.
3. The initialization time for the phase is different from what I specified.
4. The correct amount of traffic is not leaving the source.
5. The phase does not complete and stops sending out traffic after the first request.
6. How do I set my application to end after all its tasks finish?7. How do I configure my phases to use server CPU for inter-response times?
7. How can I use server processing speed for Inter-response Time -- the delay incurred by each response coming back from the server?

Detailed Problem Descriptions/Solutions:

Problem 1: I set up my tasks in a Task Configuration Object, however, there is no traffic flowing out of my workstation/LAN and the simulation runs for several hundred events only.

Solution: Make sure that the Source Preferences attribute is set on your workstation. This attribute is available in advanced node models only, so make sure that your workstation/LAN is of an advanced type. Setting this attribute effectively makes the workstation/LAN the originating node for your task.
 

Problem 2: I have setup several applications within my profiles, but I do not see all of them executing. Alternatively, I do not see an application repeating within the specified profile.

Solution: If the Operation Mode of all the applications within the profile is set to Serial (Ordered or Random) and the Profile Duration is set to the End of Simulation and the duration of the first application is set to End of Profile, only the first application will start up. Therefore, you will NOT see traffic from the second application onwards. When you run applications serially, make sure that your configuration allows all the applications to start within the specified runtime.
 

Problem 3: I have set Initialization Time for a phase to be n seconds, however, I see that the actual initialization time is more (or less) than the time that I specified.

Solution: The difference in initialization time is contributed by the settings of the CPU Resource Parameters attribute on the node. This usually happens when the attribute CPU Resource Parameters > Task Contention Mode is set to Simulate Contention. In this mode, CPU processing time might not be the same as the time specified in the Task Configuration Object.A.

If initialization time is more than n seconds: If a LAN object with multiple workstations is used, workstations may incur the initialization time at the same time and the CPU on the LAN will add contention delay to the initialization time. This can increase the initialization time for each phase and decrease the amount of traffic coming out of the LAN object.B.

If initialization time is less than n seconds: make sure that Processing Speed Multiplier is not larger than 1, since this effectively decreases the specified initialization by the multiplier factor.
 

Problem 4: I set up my custom application to generate a specific amount of traffic, however, I do not see the expected amount of traffic leaving the source.

Solution: Several factors affect the amount of traffic leaving the source at any time, which are:

• The phase configuration
• The amount of network traffic
• The load on the destination servers
• The underlying protocols.

The following list gives possible reasons why the amount of traffic leaving the source is different from the expected traffic load:

1. If you configured a task to send requests serially, for example the REQ/RESP Pattern is set to REQ > RESP > REQ > RESP (serial), and you have the Task Contention Mode on the server set to Simulate contention, multiple requests arriving at the server can cause huge delays for the responses. Because the response takes longer to arrive, the next request does not go out and the traffic stalls. This is normal behavior where multiple users experience a server slowdown and are unable to perform the next operation until their machine regains control.
   
   Note: that the total amount of traffic sent from the node is the same; however, it takes longer to send the specified amount of traffic; this makes it possible that the application/profile or simulation will finish before the task finishes. If this happens, some of the results of the custom application do not get collected.
2. Same as point (A), except that you have a long network delay instead of a server delay. If there is a network bottleneck and the request response mode is serial, the responses get delayed and the next request fails to leave.
3. If REQ/RESP Pattern is set to REQ > REQ > REQ > RESP (concurrent) and Transport Connection > Policy is set to New Connection Per Request, the number of parallel open connections will be limited to the number specified in the Limit attribute. Therefore, if the number of requests is set to 100, and the connection limit is 10, requests are sent out concurrently and the inter-request time is smaller than the time it takes to finish one request, only the first 10 requests will be able to open connections simultaneously, and the other 90 requests will get queued. From that point on, a new request will be sent out only when a previous request finishes and the connection becomes available. Thus, the specified inter-request timing will be lost. In this case, the amount of traffic sent from the workstation will be different.
4. In general, underlying transmission protocols, such as TCP, influence the amount of traffic leaving the source. If an application sends out 1000 Mbytes of traffic instantaneously, it does not mean that this will be the instantaneous amount of data leaving the source. For example, the TCP congestion window size or receive buffer sizes will influence the amount of data that can be sent out instantaneously.
    

Problem 5: I have specified a phase, but it does not seem to finish and stops sending traffic after the first request.

Solution: When you set the Dest > Source Information in a task to No Response, make sure that you select the Concurrent mode for the request response pattern. Because there are no responses, you cannot use the serial request response mode.
 

Problem 6: I want to end my application when the last task finishes, but I do not want to specify its duration manually.

Solution: For custom applications, set the application duration to End of Last Task in the Profile Configuration Object.
 

Problem 7: You can set Inter-response Time explicitly or set it to Use Server CPU, which calculates inter-response time based on the CPU speed of the destination server.

Application Modeling > Custom Applications