Cisco Cisco Customer Voice Portal Downloads 发行公告
C
HAPTER
3:
A
DMINISTRATION
U
SER
G
UIDE FOR
C
ISCO
U
NIFIED
CVP
VXML
S
ERVER
AND
C
ISCO
U
NIFIED
C
ALL
S
TUDIO
65
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. 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 Chapter 6: VXML
Server Configuration. Use the following table to reference the JMX attribute name with the
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 Chapter 6: VXML
Server Configuration. Use the following table to reference the JMX attribute name with the
global_config.xml
tag name.
JMX Attribute Name
Tag Name
LoggerMaximumThreadPoolSize
<maximum_thread_pool_size>
in the
<logger>
tag.
LoggerMinimumThreadPoolSize
<minimum_thread_pool_size>
in the
<logger>
tag.
LoggerThreadKeepAliveTime
<keep_alive_time>
in the
<logger>
tag.
SessionInvalidationDelay
<session_invalidation_delay>
Table 3-1
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 Chapter 5: VXML Server Logging). 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. 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. 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).
the “LoggerEventQueueSize” attribute. A brief explanation of how VXML Server handles
loggers is warranted (for more details refer to Chapter 5: VXML Server Logging). 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. 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. 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).
Under typical operation, the logger event queue size should not be a large number (one might see
it set to 0 to 10 most of the time). There could be spikes where the queue grows quickly but with
plenty of available threads to handle the events, the queue size should shrink rapidly. The
administrator should take note if the queue size shows a high number, though should be very
wary if this number seems to grow over time (minutes, not seconds). A growing queue size is an
indication that either the load on the system is too high for the thread pool to handle (which is
it set to 0 to 10 most of the time). There could be spikes where the queue grows quickly but with
plenty of available threads to handle the events, the queue size should shrink rapidly. The
administrator should take note if the queue size shows a high number, though should be very
wary if this number seems to grow over time (minutes, not seconds). A growing queue size is an
indication that either the load on the system is too high for the thread pool to handle (which is