Throughput Considerations
Throughput of the ActiveMatrix BusinessWorks engine is the rate at which the engine can execute and complete processes. The throughput of the engine is determined by factors that can be grouped into engine parameters and HTTP parameters.
Engine parameters
Thread Count
ThreadCount
specifies the number of process instances (jobs) that can be executed concurrently by ActiveMatrix BusinessWorks engine. By default, the thread count is eight.
TIBCO recommends that you measure the CPU and memory resources under a typical processing load to determine if the default value is suitable for your environment.
If the engine throughput has reached a plateau, but the CPU and memory are not fully utilized, you can increase the thread count to have a positive effect on the throughput. However, specifying too high value can cause CPU thrashing, or an increase in latency caused by a large number of messages in the queue. Specifying too low value can cause higher memory use and lower engine throughput as some CPU resources remain unutilized.
Each process instance consists of multiple activities that have to be executed in a sequence for the process instance to complete. If one of these activities is a blocking activity, the thread that is executing this process instance is idle and resources are under-utilized. This affects the engine’s throughput.
Step Count
You can specify the parameter, Engine.StepCount
, to control the maximum number of steps executed (unless the job is in a transaction) for a job after which the thread yields to another job ready in the job pool. A low value of StepCount
can degrade the engine performance due to frequent thread switches. A high value of StepCount
may cause less concurrency in executing jobs and hence, result in an inefficient use of CPU.
For more details about Engine.StepCount
, see Available Custom Engine Properties .
HTTP specific parameters
minProcessors
Specifies the number of threads created when the HTTP Server is started. These threads process HTTP requests. The default value of this property is 10.
Setting a high value for minProcessors
can produce a large number of excessive threads and hence block the system resources.
maxProcessors
Specifies the maximum number of threads that can be created by the HTTP Server to process incoming HTTP requests. The default value of this property is 75.
Setting a low value for maxProcessors
results in the following:
• | limiting the number of threads in the system and therefore limiting the number of requests that can be processed simultaneously. |
• | reduced memory contention. |
• | less number of context switches. |
• | increased throughput. |
Setting a high value for maxProcessors
results in the following:
• | more number of requests can be processed simultaneously. |
• | degraded throughput for all the processes. |
acceptCount
Specifies the maximum number of incoming connection requests that can be accepted when all HTTP processors are in use. Incoming requests received after the acceptCount
limit is reached are rejected. The default value for acceptCount
is 100.
When maxProcessors
is low, you may wish to set acceptCount
to a higher value so that more client requests are accepted and queued, rather than being rejected.
Enable DNS Lookups
Checking this field enables a Domain Name System (DNS) lookup for HTTP clients so that the IP address is resolved to a DNS name.
Setting this field adds latency to every request because it requires the DNS lookup to complete before the request can be completed. Since the throughput is adversely affected, this field should be set only when required.
Processor Affinity
On a multi-CPU machine, process(es) can be configured to run only on a dedicated set of CPUs using processor affinity.
Processor affinity takes advantage of the fact that some remnants of a process may remain in one processor's state (in particular, in its cache) from the last time the process ran. Scheduling it to run on the same processor the next time could result in the process running more efficiently than if it were to run on another processor.
JDBC Activities
Every JDBC Connection shared resource has a connection pool. The parameter Maximum Connections
determines the connection pool size and hence, the maximum number of connection requests that can be processed by a JDBC shared resource.
JDBC activities use engine threads to connect to a database configured in the JDBC Connection shared resource and process requests. The engine threads are released once the operation in the JDBC activity completes and the connection is closed.
For a typical scenario using a single JDBC Connection shared resource, ensure that the parameter Maximum Connections
specified is inline with the engine thread pool size specified by the property engine.ThreadCount
.