
16.2.1 Configuration
Configure the following parameters for staging configuration using the Web Console, or by editing and updating the staging
configuration XML using the Command Console.
1.
local-enabled
2.
local-maximum-size
3.
maximum-age
4.
maximum-size
5.
threadcount
16.2.2 Stage Tuning
You can observe the effects of the configuration changes in the Statistics Client by simulating heavy concurrency using a load
simulator.
For more information regarding statistics please refer to Chapter 8
16.2.3 Tuning Recommendations
The maximum size of the staging queue determines how many stage items may be queued awaiting processing. When the
queues maximum size is reached the oldest item in the queue is automatically failed and removed to accommodate new items.
The default value of 3000 is suitable for most scenarios. It is recommended to set the maximum size to be high enough that the
SLEE can ride out short bursts of peak traffic, but not so large that under extreme overload stage items are allowed to wait in
the queue for too long before being properly failed.
The
thread-count
parameter determines the number of staging threads that will service the staging queue. This parameter
has the greatest impact on overall latency of all the staging parameters and careful attention should be given to tuning the
thread-count
in order to achieve optimal performance. Again, is has been found the default value of 30 to be useful for many
applications on a wide range of hardware, however for some applications, or when using hardware with 4 or more CPU’s it may
be beneficial to increase the number of staging threads.
In particular when the SLEE is running services that perform high latency blocking requests to an external system it will often
be necessary to increase the number of staging threads.
Consider for example a credit check application that will only allow a call setup to continue after performing a synchronous call
to an external system. If a credit check takes on average 150ms this means the staging thread processing the call setup event will
be blocked and unable to process other events for 150ms. With the default configuration of 30 staging threads such a system
would be able to handle an input rate of approximately 200 events/second. Above this rate the stage worker threads will not
be able to service event processing stage items fast enough and stage items will begin to backup in staging queues, eventually
causing some calls to be dropped. In this example the problem is easily solved by configuring additional staging threads.
In real world applications it is seldom a matter of applying a simple formula to work out the optimal number of staging threads,
it is recommended to use performance monitoring tools to examine the behaviour of staging alongside such metrics as event
processing time and system CPU usage to find a suitable value for this parameter.
The
maximum-age
setting determines the maximum time an item of work can remain in the staging queue and still be consid-
ered valid for processing upon removal. Tuning of this parameter (along with
maximum-size
) is useful for determining your
application’s behaviour under overload conditions.
The
local-enabled
,
local-initial-size
and
local-maximum-size
parameters are useful for reducing latency and, to a
lesser extent, CPU usage in some applications by controlling thread affinity for related items of work. These parameters become
useful when an event processing stage item is submitted to staging by a staging thread. This would happen for example if SBB
event handler code being executed on a particular staging thread fires an event using an SBB fireXXEvent() method and the
transaction commits.
With local staging queues disabled the stage item for the fired event will enter the staging queue just like any other event.
Open Cloud Rhino 1.4.3 Administration Manual v1.1 95
Comentarios a estos manuales