The code within a Transformer pipeline (Lua) module can run in multiple threads. The configuration items described here enable you to monitor how the threads handle the throughput for the various pipelines, and to tune the threads accordingly.
|Some of these configuration items relate to pipeline messages.A message is posted to a pipeline whenever the pipeline needs to handle a subscription request, subscription discard, data update, nodata event, UDP signal message, monitoring message, or pipeline action message (add new pipeline, shut down pipeline, and so on).|
num-threads Specifies the number of worker threads that the pipeline module spawns. Worker threads are used to process updates and nodata events.
When the first update for a subject arrives inside the pipeline module, one of the worker threads is chosen in a round-robin manner and the update is assigned to it for processing. All subsequent updates are then passed to the same update thread; this ensures that updates for a particular subject are always processed in the order they were received.
threads-latency-enable when set to
TRUE, enables the latency of pipeline threads to be calculated. The latency is a measure of how fast a thread processes pipeline messages.
FALSE (thread latency is not calculated)
threads-max-messages-to-process specifies the maximum number of pipeline messages to process. It applies to all threads and is a tuning mechanism to stop any one thread being locked up by handling too many incoming messages. A thread processes no more than
threads-max-messages-to-process messages at a time before breaking out of its processing loop to allow other events (such as timed events) to be serviced.
The default setting should normally be sufficient.
threads-queue-report-logfile specifies the name of the file to which the sizes of the thread queues are reported.
Default value: (no log file is created, so thread queue sizes aren’t logged)
threads-queue-report-period specifies the interval in seconds at which thread queue sizes are reported to the