Refactoring for Increased Throughput
Article ID: KB0074458
Updated On:
| Products | Versions |
|---|---|
| TIBCO Streaming | 7 |
Description
Simply adding another adapter instance to split the load between two adapters results in lower performance from each adapter instance.
Issue/Introduction
Refactoring for Increased Throughput
Resolution
Adding a second adapter and splitting the load often creates a downstream bottleneck when the two inputs come together in the same thread and use shared resources. This bottleneck results when a tuple cannot exit the flow before another tuple is ready to be emitted from one of the two adapters.
To resolve this isolate each adapter instance in its own concurrent sub-module and duplicate the downstream flow into each of these modules as much as possible. The ideal case to achieve high throughput occurs with designs where the output of each adapter never uses a resource which might be shared by the output from another adapter.
The most common shared resource is a Query Table which is written to by updates from each adapter instance. This can cause blocking behavior because Query Tables are table-locked, so only one write can occur at a time. Also note that read-activity alone can occur in parallel from multiple threads (also called parallel or concurrent regions), but read activity also blocks write activity. When writes are waiting on long read operations, the read operation is materialized (the data is copied out of the table) so the write can proceed. This causes additional memory allocation to duplicate the data and additional garbage collection when the materialized data is no longer needed. Although this allows write activity to block for a shorter period of time, it costs memory and additional CPU time to perform the materialization and garbage collection.
If the bottleneck is continuous blocking on writes to a Query Table, see if the Query Table can be split so sharing is reduced or elimintated and any read activity reduced in frequency or delayed to periods of less demand. The same approach can be used for other shared resources.
For more information on concurrency and tuple processing across parallel regions, see Help topic:
TIBCO StreamBase Documentation > Administration Guide > Tuning StreamBase Applications > StreamBase Execution Order and Concurrency
To resolve this isolate each adapter instance in its own concurrent sub-module and duplicate the downstream flow into each of these modules as much as possible. The ideal case to achieve high throughput occurs with designs where the output of each adapter never uses a resource which might be shared by the output from another adapter.
The most common shared resource is a Query Table which is written to by updates from each adapter instance. This can cause blocking behavior because Query Tables are table-locked, so only one write can occur at a time. Also note that read-activity alone can occur in parallel from multiple threads (also called parallel or concurrent regions), but read activity also blocks write activity. When writes are waiting on long read operations, the read operation is materialized (the data is copied out of the table) so the write can proceed. This causes additional memory allocation to duplicate the data and additional garbage collection when the materialized data is no longer needed. Although this allows write activity to block for a shorter period of time, it costs memory and additional CPU time to perform the materialization and garbage collection.
If the bottleneck is continuous blocking on writes to a Query Table, see if the Query Table can be split so sharing is reduced or elimintated and any read activity reduced in frequency or delayed to periods of less demand. The same approach can be used for other shared resources.
For more information on concurrency and tuple processing across parallel regions, see Help topic:
TIBCO StreamBase Documentation > Administration Guide > Tuning StreamBase Applications > StreamBase Execution Order and Concurrency
Feedback
Yes
No
Powered by
