Cisco Cisco Workload Automation 6.3 Referencia técnica
38
Tuning CWA
Configuration and Tuning
CacheSynchronizer.NumThreads (4) – number of concurrent threads spawned to sync the cache. More threads
increase throughput, but use more CPU and memory. Recommend to set at or below number of physical cores on
machine.
increase throughput, but use more CPU and memory. Recommend to set at or below number of physical cores on
machine.
CacheSynchronizer.StreamCommitSize (1000) – number of records committed to the cache in a batch. Larger
batches improve throughput, but use more memory.
batches improve throughput, but use more memory.
The following master.props properties are what you would tune for the connections used to read/write to the Master
database:
database:
Shared between normal Master operation PLUS cache sync (both can be high I/O).
Each Client Manager can configure X number of sync threads = Master needs X number of DB connections.
DatabaseConnections (20)
Master Messaging
Master messaging impacts only the Master, but it has a big impact on the performance of the Master and thus indirectly
the Client Manager as well. The Master is designed to be a heavily multi-threaded application. By tuning the messaging
parameters, the Master is bettter able to utilize the threading capabilities of the system.
the Client Manager as well. The Master is designed to be a heavily multi-threaded application. By tuning the messaging
parameters, the Master is bettter able to utilize the threading capabilities of the system.
All work in the Master is performed by the following message threads:
Message Queues
Before a message is sent to an object, it is first posted to one of the application’s message queues. Each queue or
set of queues is allocated for a specific type of message. For example, the default queues are for general messages,
the compiler queue is for compile messages, and the communication queues are for communication messages. Each
queue has a priority that determines how often its messages get processed. Higher priority queues have their
messages processed more frequently than lower priority ones.
set of queues is allocated for a specific type of message. For example, the default queues are for general messages,
the compiler queue is for compile messages, and the communication queues are for communication messages. Each
queue has a priority that determines how often its messages get processed. Higher priority queues have their
messages processed more frequently than lower priority ones.
Message Threads
Message threads are the workhorse of the application. They are responsible for pulling messages out of queues and
then executing them. Depending on the application configuration, there may be anywhere from a dozen to a hundred
threads running inside the application. Generally speaking, more threads equal better performance, since each CPU
can execute a thread at the same time as another CPU. So, technically, a dual core system can process twice as
many messages as a single core system. However, in reality, because each thread eats up a bit of memory and CPU,
performance is expected to degrade when there are too many threads for the system to handle.
then executing them. Depending on the application configuration, there may be anywhere from a dozen to a hundred
threads running inside the application. Generally speaking, more threads equal better performance, since each CPU
can execute a thread at the same time as another CPU. So, technically, a dual core system can process twice as
many messages as a single core system. However, in reality, because each thread eats up a bit of memory and CPU,
performance is expected to degrade when there are too many threads for the system to handle.
Message Thread Pools
A message thread pool groups together a set of messages threads with a set of message queues. The intent is to
force threads from a pool to only process messages for queues from the same pool. This guarantees if threads in
one pool are busy, messages in another pool will still get processed by free threads in that pool.
force threads from a pool to only process messages for queues from the same pool. This guarantees if threads in
one pool are busy, messages in another pool will still get processed by free threads in that pool.
To configure the Master messaging:
MessageThreads = general workhorse threads
SpecialMessageThreads = adapter-related threads
EventMessageThreads = event-related threads
CommThreads = communication threads
Note:
As a best practice, retain no more than 20 M message log records for better performance.