Thread Pool Sizing Guidelines

When configuring thread pool size, bigger is not always better! More concurrently running threads requires more server resources (e.g. RAM and CPU), so increasing the thread pool size past a certain point could start to decrease performance rather than improve it. In most cases, a thread pool size of 10 provides a good balance between concurrent processing and server resource optimization. Anything between 10-100 should typically be fine for the Thread Pool. Also, it is often just as (if not more) important to configure the IIS App Pool Queue Length Limit appropriately as to fine tune the Thread Pool size.

If all of your process' activities are "short-duration" ones, then you may not need many threads, because the only way that "short-duration" activities alone would typically cause AgilePoint to (simultaneously) utilize the maximum number of threads in the Thread Pool is if a large number of such activities were entered/activated nearly simultaneously. However, if you have a mixture of "long-running" activities and "short-duration" activities, then increasing thread pool sizes may help considerably because "short" activities that start in the "middle" of a long running activity will not have to wait for it to end before being processed. In general, if you analyze a given time period, then increasing either the quantity or the average duration of activities that are active within that time period will increase the likelihood that some of those activities will require concurrent processing (and therefore require a larger Thread Pool size). However, in certain environments, usage patterns may also have a significant affect, and may render some of the above guidelines less (or more) accurate.

In the above context, a "long-running" activity is defined as one that will require server resources for a length of time long enough that it may overlap with other/subsequent activities or processing. Examples of long running activities could include: synchronous AgileParts that require several minutes (or even hours) of processing to complete; Web Service activities with a large timeout value; AgileShapes that interact with (and may have to wait for data from) other servers or systems; etc.

Conversely, a "short-duration" activity is one that will only consume server resources for a brief period. Examples of such activities include: AgileParts that perform minimal processing; Manual activities (or AgileWorks that perform minimal server-side processing); Single- or Multiple-Condition AgileShapes; etc. Note that Manual activities are normally considered to be "short-duration" activities regardless of the activities' time span or due date, because the AgilePoint server's resources are not being used during most of the activities' duration.

Another way to consider the issue is to determine how frequently new processes will be initiated/launched, how long each process takes to complete, and how much of that time is spent on "automatic" activities that are performed by the server. If you have many long-running processes running simultaneously, and each one contains automatic activities that require minutes (rather than seconds or microseconds) to complete, then you are much more likely to have simultaneous workflow processing occurring, which would require more threads for optimal performance.

See below for a list of guidelines that should be helpful in determining a good Thread Pool size for most environments.