Types of Threads in ThingWorx
The following threads are generally available by default in the ThingWorx environment. Depending on your database or customizations, you may see some additional thread types.
• https nio (Number of threads 1-1024+)
Threads that are used for user requests or REST payloads. All external requests initially come through the nio (non-blocking IO) threads before executing on a different thread type. You can configure more than 1024 threads. In Apache Tomcat, the default number of threads is 150.
• WSExecutionProcessor (Number of threads 1000+)
Threads that are used for remote device communications, for example, Kepware. Generally, only a few of these threads are actively running; 99% of the time these threads are in waiting state. These threads are configured using the WebSocket Execution Processing subsystem. A bottleneck in the device communication is identified if all these threads are busy, or if the WebSocket Execution Processing subsystem shows a growing queue of events.
• TWEventProcessor (Number of threads 16+)
Threads that are used to execute code for all events, timers, and schedulers. When these threads are busy, events go in a queue. If the queue backs up significantly, it may impact the server performance. If all the event threads are constantly busy, the server may start to become unresponsive and may fail to respond to user input. These threads are one of the main thread types, and it is recommended to monitor them. The number of active threads is configurable and can be monitored using the Event Processing subsystem. A bottleneck in event, timer, or scheduler execution can be identified if all the threads of this type are busy. In this case, activeThreads in the Event Processor subsystem is consistently high and there is a growing queue of events in this subsystem in the ThingWorx Composer.
• C3P0 (Number of threads 3-8)
Threads that manage all the database connections. If the threads are blocked for long periods, it leads to database access issues.
• Timer or schedulers (Number of threads 30-40)
Threads that are used to monitor and trigger schedulers and timers. The code execution occurs on TWEventProcessor threads. These threads do not perform significant processing work. They time the events that are required to start additional processing.
• pool (Number of threads 40+)
Threads that are used for writing persisted properties, stream, and value stream entries. An internal timer triggers these threads and most of the time the threads are idle. Some of these threads correspond to the stream and value stream Processing subsystems. If the queue in these subsystems increases, it indicates database throughput issues. The corresponding threads are saturated with activity.
• Async threads (Number of threads 1-100+)
Business logic is triggered on separate threads if the underlying services are marked as async. The number of async threads can spike as high as several thousand. The name of the service that triggers the thread is a part of the thread name.
• Various JVM or Tomcat Apache threads (number of threads: 40+)
Threads that are used for internal server operations at the Tomcat Apache layer. Generally, these threads are not analyzed as they do not trigger performance bottlenecks.