The System tab of the AgilePoint Server Configuration utility provides the user interface to configure the maximum number of threads that AgilePoint will be able to use at runtime while handling workflow requests. When the thread pool is configured via this utility it sets both the Event Capacity (for processing AgileWorks) as well as the Working Capacity (for processing AgileParts). In most cases, the same thread pool size as configured via the utility is sufficient for both the Working Capacity as well as the Event Capacity.
For thread pool sizing, anything between 10-100 should be fine. In most cases, a thread pool size of 10 provides a good balance between concurrent processing and server resource optimization.
In some cases, additional tweaking of thread pool sizing may improve performance when heavy CPU usage is apparent for processing AgileParts versus AgileWorks. This finite control over thread pool sizing can be accomplished via the AgilePoint Server Configuration file (i.e., netflow.cfg).
As stated above, when using the AgilePoint Server Configuration utility to set the Thread Pool Size, the value entered, sets both the Event Capacity (for processing AgileWorks) as well as the Working Capacity (for processing AgileParts). However, manual customization can be done via the netflow.cfg to adjust the Working Capacity for a thread pool without changing the Event Capacity or vice versa. For example, if your CPU is processing a large number of AgileParts rather than AgileWorks, you may want to increase the Working Capacity thread pool size, and leave the Event Capacity as is. Improving AgilePart performance is the key to improving capacity because AgilePart processing can cause a bottleneck.
To modify the netflow.cfg file for thread pool optimization, follow these steps.