Extending subsystem management during a test run

Here are additional examples of the services that subsystems provide:

• Tracking server responses. For example, consider tests in which an HTTP request is sent to a server, and you need to know when the response returns. Instead of tying up a thread to wait for the response, a subsystem can do this while the rest of the threads perform other actions. The subsystem can provide notification or reissue an action when the server response occurs.
• Handling asynchronous communication.
• Managing the sleeping action for virtual users.
• Managing logging. For example, creating a custom execution history can take a long time. You can assign a subsystem to do this without tying up a thread with this process. You can set up a subsystem to take care of the special logging actions while the rest of the actions perform other things.

Creating the performance test engine subsystem sample

A performance test engine subsystem provides services to one or more actions. An action that uses a subsystem during a test run is known as a recurrent action. Most actions contain finish() at the end of their execute(). A recurrent action requests service from a subsystem before the end of execute(). After the service is provided, the subsystem that provides the service updates state information in the action and reissues the action for execution. Based on the state information, a performance test engine worker thread takes a different course of execution during the recurring call to execute() and eventually calls finish() to end the action.