Contents
Most StreamBase operators support one or more concurrency options that, in some cases, allow you to speed up your StreamBase applications. This page describes the basics of setting the concurrency options for operators. See Execution Order and Concurrency for an in-depth discussion of the principles supporting the concurrency options.
Most StreamBase operators and adapters can be configured:
-
To run each instance of a operator, module, or adapter in its own parallel region
-
To run with multiple copies of itself for parallel processing
-
For both options
Concurrency options are configured in the Concurrency tab of an operator's Properties view.
The EventFlow Editor shows that the Separate Threading concurrency option is enabled for a component by marking that component's icon with a circle within its tile boundaries.
|
The concurrency setting Multiplicity, when set to multiple with a number of instances setting of two or more, is shown with an overlaid number that reflects the number of instances.
|
Operators that support separate threading have a check box at the top of the Concurrency tab of their Properties view. When the Multiplicity option is set to single (the default setting), the threading option is labeled Run this component in its own thread. When Multiplicity is set to multiple, the threading option is labeled Run each instance of this component in its own thread.
This option can apply to:
-
A single operator, which would run in a thread independent of the main application.
-
Multiple instances of an operator, if the operator supports both multiplicity and separate threading. In this case, each instance of the operator runs in its own thread.
-
A module referenced by a Module Reference operator.
-
One or more module instances in an Extension Point operator, each of which would run in a separate thread.
A component is a candidate for separate threading if the component is long-running or compute-intensive, can run without data dependencies on other StreamBase components, and would not cause the containing module to block while waiting for the component to return. If your component meets these criteria, you may be able to improve performance of the overall application by specifying separate threading.
This option causes StreamBase Server to process the component, module, or module instances concurrently with other processing in the application. The operating systems supported by StreamBase automatically distribute the processing of threads across multiple processors.
Caution
The separate thread setting is not suitable for every application, and using this setting requires a thorough analysis of your application. For a background discussion, see Execution Order and Concurrency, which includes important guidelines for using the concurrency options.
Multiplicity refers to the number of instances of an operator, module, or module instance. To specify more than one instance of this component, select multiple in the Multiplicity control, and enter a number of instances. When changing from single to multiple multiplicity, Studio starts with 2 in the Number of instances field. Change this as your application requires.
For example, for a Filter operator with a complex, compute-intensive filtering algorithm, you can specify that the Filter operator run with a multiplicity of 2. In this case, two instances of the Filter operator run in parallel.
You can combine a multiplicity setting with separate threading. In this case, each instance of the operator runs in its own thread.
Multiplicity can apply to:
-
A single operator.
-
A module referenced by a Module Reference.
A multiplicity setting greater than one does not automatically improve your application's performance. The situations in which a component can take advantage of multiplicity are complex. See Execution Order and Concurrency for background information and guidelines.
Caution
Like threading, a multiplicity setting of 2 or more is not suitable for every application, and using this setting requires a thorough analysis of your application. For a background discussion, see Execution Order and Concurrency, which includes important guidelines for using the concurrency options.
Important
StreamBase does not support exporting a Query Table from a Module Reference with a multiplicity setting greater than 1.
When an operator or module is set to run with multiple instances, or when two or more module instances of an Extension Point are run, StreamBase's default behavior is to broadcast incoming tuples equally to each instance of the operator or module. However, you can optionally specify non-default styles for dispatching incoming tuples to operator or module instances. This subject is discussed on Dispatch Styles.
The Number of instances field can take a parameter in
the form ${param}, where param is defined in the Definitions tab of the
EventFlow Editor of the same module, or is otherwise passed to the containing module.
|
The following table shows the varying operator support for concurrency features:
| Component | Separate Threading | Multiplicity | Dispatch Styles |
|---|---|---|---|
| Aggregate | yes | yes | yes |
| BSort | yes | yes | yes |
| Extension Point | yes | — | yes |
| Filter | yes | yes | yes |
| Gather | yes | yes | yes |
| Heartbeat | yes | yes | yes |
| Iterate | yes | — | — |
| Java Adapters, all custom and global | yes | yes | yes |
| Java Operators, all custom and global | yes | yes | yes |
| Join | yes | yes | yes |
| Lock | — | — | — |
| Map | yes | yes | yes |
| Merge | yes | yes | yes |
| Metronome | yes | — | — |
| Module Reference | yes | yes | yes |
| Pattern | yes | yes | yes |
| Query with Query Table or Materialized Window | — | — | — |
| Query with JDBC Table | yes | yes | yes |
| Sequence | — | — | — |
| Split | yes | — | — |
| Union | yes | — | — |
| Unlock | — | — | — |
The following shows the same information as the table above, organized in a different way.
- Operators that support Separate Threading, Multiplicity, and Dispatch Styles
-
Aggregate, BSort, Filter, Gather, Heartbeat, Join, Map, Merge, Module Reference, Pattern, Query operator when associated with a JDBC Table, all custom or global Java operators, all custom or global Java adapters
- Operators that support Separate Threading only
-
Iterate, Metronome, Split, Union
- Special Case: Operator that supports Separate Threading and Dispatch Styles
-
Extension Point
- Operators with no support for concurrency options
-
Lock, Unlock, Sequence, Query associated with a Query Table or Materialized Window