Async Service Test Driver - learn-tibco-cep/tutorials GitHub Wiki
The Async Service tutorial includes a multi-threaded client simulator used to support performance testing. It is implemented in the project folder TestDriver. This page describes the implementation of the Test Driver.
Engine Startup
As specified in the Demo.cdd, when the Test Driver agent starts, it calls the startup function, which schedules a number of randomly delayed timer events, and so multiple request publishers can kick off later at a different time.
It also calls the initializeStats function to start the Performance Stats Collector.
Delayed Dispatcher
Each timer event scheduled at the engine startup will trigger the DelayedDispatch rule, which will send a Dispatch event to start a request publisher on a separate engine thread.
Client Request Publisher
When a Dispatch event is sent to its default destination on a Local channel, it executes the preprocessor function publishClientRequests as configured in Demo.cdd for the local event destination.
The preprocessor function will then continue to publish client requests at a pre-configured event rate, which drives the performance testing of the Async Service handler.
Client Response Handler
The Demo.cdd also specifies a preprocessor function for the FTL destination of Client Response events. The preprocessor function onClientResponse will update the performance statistics and print out the stats periodically.
Engine configuration
The Test Driver is configured using the following global variables, whose default values can be overridden by properties of the test PU in Demo.cdd.
| Variable Name | Description | Default |
|---|---|---|
| Test/Publishers | Number of concurrent publisher threads | 3 |
| Test/RequestCount | Number of requests to send per thread | 1001 |
| Test/RequestInterval | ms to sleep between consecutive requests | 20 |
| Test/PrintStats | Print stats after receiving this number of responses | 200 |
Tips
The following practical tips are used in the Test Driver implementation. They may be useful for other BE application scenarios too.
Use timer events to schedule delayed tasks
The startup function schedules multiple multiple timer events with specified time delays and an event context. The delayed timer event will then trigger the action of a rule DelayedDispatch. This is a pattern used to execute a delayed task, e.g., to complete a time-boxed activity.
Use local channel to spawn multiple threads
Instead of starting a request publisher in the DelayedDispatch rule directly, the rule sends a Dispatch event to a local channel destination, which executes the dispatched task on its own thread. This BE application pattern prevents the single timer thread from blocked by long lasting tasks, which would delay the execution of subsequent timers on the thread. It is also a common technique to spawn multiple concurrent threads since BE does not allow you to create threads explicitly.
Use Global Variables for configurable parameters
Global Variables are parameters that can be configured at deployment time. They usually depends on the deployment environment and required runtime characteristics, such as connection info for other services.
The default values of global variables are fixed when the ear file is built. But the actual value at runtime can be configured in either the CDD file or the engine tra file. Note that the global variable name must be prefixed by tibco.clientVar. in the configuration. For example, in Demo.cdd, the variable Test/Publishers for the test PU is configured as
tibco.clientVar.Test/Publisher = 3