Copyright © Cloud Software Group, Inc. All Rights Reserved

Performance Considerations

This section describes the memory and throughput considerations to be made, while tuning factors affecting the performance of a BusinessWorks engine.

Memory Considerations

Engine parameters

Max jobs

If the number of process instances in memory have reached the value of Max Jobs, then the process instances created are temporarily held on a disk. These process instances will be moved back into memory when sufficient memory is available.

Flow limit

When the job processing starts lagging, the memory allocated to the job pool is utilized by the new jobs created and can exhaust the job pool. The FlowLimit property can be set to specify the number of jobs that can reside in the job pool.

Once the job pool is full, the job creator is suspended and is in a FLOW_CONTROLLED state. The job creator comes out of the FLOW_CONTROLLED state after approximately half the value specified for FlowLimit jobs are executed to completion.

 

Activation limit

Activation Limit can be set if a job that is blocked should remain in memory till completion. Setting the ActivationLimit affects the engine performance substantially.

JVM parameters

Every BusinessWorks engine runs in a Java Virtual Machine. As a result, the settings on the JVM influence the engine performance. Java provides some parameters to tune the memory usage and optimize engine performance.

Heap size

Following parameters are used to set the heap size for the engine:

-Xms: Minimum amount of memory used

-Xmx: Maximum amount of memory used

TIBCO BusinessWorks 5.2.0 and higher versions may see an increase in memory footprint and a potential memory sizing issue. This is because TIBCO BusinessWorks version 5.2.0 and above point to server JVM, while versions older than TIBCO BusinessWorks 5.2.0 point to client JVM in the bwengine.tra file. While sizing and tuning your environment, consider the following: • The total memory used by the JVM (memory footprint) is dependent on the type of JVM used (Server JVM or Client JVM), the JVM version, and the JVM vendor. • A Server JVM occupies a higher memory footprint and may result in higher performance when compared to a Client JVM. • A Client JVM may have a lower startup time and memory footprint. For more information on tuning the JVM to suit your application, refer to the JVM Tuning Guide of the JVM used in your environment. You may also consult your JVM vendor for details about the exact memory footprint and heap management in the JVM version used in your environment.

Garbage collection

The java object, such as a job, occupies memory from the time it is created to the time it is destroyed. Java provides garbage collection, an automated mechanism to clean up objects that still exist but are no longer used.

To retrieve the garbage collection metrics for the BusinessWorks engine, specify the -verbose:gc option when starting the JVM used by the engine.

You can set the Java memory parameters by using the java.extended.properties option in the bwengine.tra file.

For example, specify the following in the bwengine.tra to set the heap size to 768M and retrieve the garbage collection metrics for the engine.

java.extended.properties -Xms768m -Xmx768m -verbose:gc

Throughput Considerations

Throughput of the 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 BusinessWorks engine. By default, the thread count is eight.

It is recommended 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.

See Available Custom Engine Properties for more details on Engine.StepCount.

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.

Copyright © Cloud Software Group, Inc. All Rights Reserved