Talk:Thread Processing Guidance

2026-02-06 DGreenwood

Consider an alternative tone

Grooper Activity Processing services are responsible for distributing processing resources to automated tasks within a Batch Process. This article describes how threads are used by Grooper and provides recommended best practices for thread allocation and service configuration.

What is a thread?

A thread is the smallest unit of execution managed by an operating system. Threads represent individual execution paths that allow work to be performed concurrently within an application.

Threads are the execution units used by software to perform work.
Performance cores typically support two threads per core.
Efficiency cores typically support one thread per core.

Determining the number of available threads

The number of threads available on a system depends on the CPU architecture and whether the system is physical or virtual.

Physical machines

Open Windows Task Manager.
Navigate to Performance → CPU.
Threads are displayed as Logical processors.

Virtual machines

Open Windows Task Manager.
Navigate to Performance → CPU.
Threads are displayed as Virtual processors.

How Grooper utilizes threads

Activity Processing

Threads are primarily consumed by Activity Processing services to execute Activity tasks in a Batch Process.

Each Activity Processing service has a configurable Number of Threads setting that defines its maximum concurrent execution capacity.
Multiple Activity Processing services may be installed on a single machine.
Activity Processing services may also be installed on multiple machines connected to the same Grooper Repository to distribute processing workloads across servers.

Web application

Threads are also used by the Grooper Application Pool on the Grooper Web Server to service user interactions with the Grooper Web Application.

Activity Processing service sizing considerations

For most workloads, distributing available threads across multiple Activity Processing services provides better throughput and stability than allocating a large number of threads to a single service.

A common and effective configuration is 3–4 threads per Activity Processing service.
Example: On a processing server with 50 available threads, overall throughput is typically higher when running 16 Activity Processing services configured with 3 threads each than when running a single service configured with all 50 threads.

Use of Processing Queues

Processing Queues control how threads are assigned to specific steps within a Batch Process and help prevent resource contention.

Processing Queues are associated with both Batch Process Steps and Activity Processing services.
- Batch Process Steps reference a Processing Queue using the Queue Name property.
- Activity Processing services bind to Processing Queues using the Queue Name property.
Processing Queues should be used to isolate resource-intensive or long-running Activity tasks.
Without Processing Queues, long-running tasks may occupy all available threads, causing other Batch Process Steps to remain idle.

Example:*

The Recognize step commonly requires more processing time due to OCR operations. If all threads are consumed by Recognize tasks, subsequent steps will not begin processing until those threads become available.