ThingWorx でのスレッドのタイプ
ThingWorx 環境では一般的にデフォルトで次のスレッドがあります。データベースやカスタマイズに応じて、このほかにもいくつかのスレッドタイプが表示されることがあります。
https nio (スレッド数 1-1024+)
ユーザーリクエストまたは REST ペイロードに使用されるスレッド。別のスレッドタイプで実行する前に nio (非ブロック IO) スレッドから最初に送信されたすべての外部リクエスト。1024 個以上のスレッドを設定できます。Apache Tomcat では、デフォルトのスレッド数は 150 です。
WSExecutionProcessor (スレッド数 1000+)
Kepware などのリモートデバイス通信に使用されるスレッド。通常、アクティブに実行しているのはこれらのスレッドのうちの一部だけであり、99 % の時間、これらのスレッドは待機状態になっています。これらのスレッドは WebSocket 実行処理サブシステムを使用して設定されています。これらすべてのスレッドがビジーであるか、WebSocket 実行処理サブシステムでイベントのキューが増大していることが示された場合、デバイス通信におけるボトルネックが特定されます。
TWEventProcessor (スレッド数 16+)
すべてのイベント、タイマー、スケジューラのコードの実行に使用されるスレッド。これらのスレッドがビジーである場合、イベントはキューに入ります。キューが著しく滞った場合、サーバーのパフォーマンスに影響を与える可能性があります。すべてのイベントスレッドが常にビジーである場合、サーバーは応答不能になり、ユーザー入力に応答できなくなることがあります。これらのスレッドはメインスレッドタイプの 1 つであり、これらのスレッドを監視することが推奨されます。イベント処理サブシステムを使用して、アクティブスレッドの数を設定および監視できます。このタイプのすべてのスレッドがビジーである場合、イベント、タイマー、またはスケジューラの実行におけるボトルネックを特定できます。この場合、イベント処理サブシステムの activeThreads が常に高い状態になり、ThingWorx Composer でこのサブシステムのイベントのキューが増大しています。
C3P0 (スレッド数 3-8)
すべてのデータベース接続を管理するスレッド。スレッドが長時間ブロックされている場合、データベースへのアクセスに問題が生じます。
タイマーまたはスケジューラ (スレッド数 30-40)
スケジューラおよびタイマーの監視とトリガーに使用されるスレッド。コードの実行は TWEventProcessor スレッドで発生します。これらのスレッドは大量の処理作業は実行しません。これらは追加処理を開始する必要があるイベントの時間を調整します。
pool (スレッド数 40+)
永続化されたプロパティ、ストリーム、および値ストリームエントリの記述に使用されるスレッド。これらのスレッドは内部タイマーによってトリガーされ、ほとんどの時間はアイドル状態になっています。これらのスレッドの一部はストリーム処理サブシステムおよび値ストリーム処理サブシステムに対応しています。これらのサブシステム内のキューが増大した場合、データベースのスループットに問題があります。対応するスレッドがアクティビティでいっぱいになっています。
非同期スレッド (スレッド数 1-100+)
基礎となるサービスが非同期としてマークされている場合、ビジネスロジックは別個のスレッドでトリガーされます。非同期スレッドの数は数千個まで増加することがあります。スレッドをトリガーしたサービスの名前がスレッド名に含まれています。
JVM または Tomcat Apache の各種スレッド (スレッド数: 40+)
Tomcat Apache レイヤーで内部サーバーオペレーションに使用されるスレッド。一般に、これらのスレッドはパフォーマンスのボトルネックを引き起こさないので、分析されません。