Cisco Cisco Customer Voice Portal 8.0(1) User Guide
VXML Server Configuration Options
To view the VXML Server configuration options using the JMX interface, navigate to the
Global/Configuration
MBean.
There are five attributes listed.
•
The first, named LoggerEventQueueSize, will show the current size of the queue that holds
logger events waiting to be sent to loggers and is not editable.
logger events waiting to be sent to loggers and is not editable.
•
The next three are related in that they control aspects of the logger thread pool.
•
The final configuration option deals with a period of time VXML Server waits after a caller
ends their call before the call session is invalidated. All of these options affect the performance
of the system and are defined fully in
ends their call before the call session is invalidated. All of these options affect the performance
of the system and are defined fully in
.
Use the following table to reference the JMX attribute name with the
global_config.xml
tag name.
Tag Name
JMX Attribute Name
<maximum_thread_pool_size>
in the
<logger>
tag
LoggerMaximumThreadPoolSize
<minimum_thread_pool_size>
in the
<logger>
tag
LoggerMinimumThreadPoolSize
<keep_alive_time>
in the
<logger>
tag
LoggerThreadKeepAliveTime
<session_invalidation_delay>
SessionInvalidationDelay
Tuning Logger Options
The most important indication of whether VXML Server is encountering issues with loggers is
the LoggerEventQueueSize attribute. A brief explanation of how VXML Server handles loggers
is warranted (for more details refer to
the LoggerEventQueueSize attribute. A brief explanation of how VXML Server handles loggers
is warranted (for more details refer to
). In order to prevent
logging from holding up calls, all logging is done in separate threads. The threads are managed
within a thread pool, which has a maximum and minimum value. When VXML Server starts
up, the thread pool allocates the minimum number of threads. As calls begin to be handled, they
generate logger events, which are put into a queue of events.
within a thread pool, which has a maximum and minimum value. When VXML Server starts
up, the thread pool allocates the minimum number of threads. As calls begin to be handled, they
generate logger events, which are put into a queue of events.
The activation of a logger event also prompts VXML Server to request a thread from the pool
and in that thread have the appropriate logger handle the top most event in the queue. The length
of time this thread handles the event depends on the logger, but the event is typically handled
in a very short period of time, measured in milliseconds. However as call volume on the system
increases, more threads are used simultaneously to handle the increase in logger events added
to the queue.
and in that thread have the appropriate logger handle the top most event in the queue. The length
of time this thread handles the event depends on the logger, but the event is typically handled
in a very short period of time, measured in milliseconds. However as call volume on the system
increases, more threads are used simultaneously to handle the increase in logger events added
to the queue.
As more threads are needed, the thread pool grows until it reaches the maximum number of
threads allowed. At that point the queue would grow until threads become available. Threads
that complete their work and cannot find new logger events to handle because the queue is
empty will be garbage collected after a certain amount of time being idle (this is governed by
the LoggerThreadKeepAliveTime option).
threads allowed. At that point the queue would grow until threads become available. Threads
that complete their work and cannot find new logger events to handle because the queue is
empty will be garbage collected after a certain amount of time being idle (this is governed by
the LoggerThreadKeepAliveTime option).
User Guide for Cisco Unified CVP VXML Server and Cisco Unified Call Studio Release 8.0(1)
71
Chapter 3: Administration
Configuration Updates