Cisco Cisco Unified Customer Voice Portal 10.5(1) User Guide
C
HAPTER
5:
V
OICE
XML
S
ERVER
L
OGGING
V
OICE
XML
S
ERVER
U
SER
G
UIDE
FOR
C
ISCO
U
NIFIED
C
USTOMER
V
OICE
P
ORTAL
R
ELEASE
4.0(1)
72
“activity_logYYYY-MM-DD-HH-MM-SS.txt” where YYYY is the year, the first MM is the
month, DD is the day, HH is the hour (in 24-hour time), the second MM is the minute, and
SS is the second that the file is created. The time information is included in the file name in
order to ensure uniqueness.
month, DD is the day, HH is the hour (in 24-hour time), the second MM is the minute, and
SS is the second that the file is created. The time information is included in the file name in
order to ensure uniqueness.
Activity Logger Configuration: Caching
The Activity Logger has the ability to use a memory cache to store information to log until either
the cache fills or the call ends. Using a cache has several advantages. The first is that it increases
performance by waiting until the end of the call to perform the file IO. Without a cache, the log
file would be updated each time an event occurred. Another advantage is that with caching on,
the log file will be more readable by grouping the activities belonging to a single phone call
together. Without the cache, the events for all calls being handled by every application running
on the VoiceXML Server would be intermingled. While one can still sort the calls after the log is
imported to a spreadsheet or database, it is much more difficult to track a single call when simply
reading the log file without the cache. The one disadvantage of using a cache is that the log file is
not updated in real-time, only after a call has completed. Should there be a desire to have the logs
updated immediately after the events occur, then caching should be left out of the configuration.
the cache fills or the call ends. Using a cache has several advantages. The first is that it increases
performance by waiting until the end of the call to perform the file IO. Without a cache, the log
file would be updated each time an event occurred. Another advantage is that with caching on,
the log file will be more readable by grouping the activities belonging to a single phone call
together. Without the cache, the events for all calls being handled by every application running
on the VoiceXML Server would be intermingled. While one can still sort the calls after the log is
imported to a spreadsheet or database, it is much more difficult to track a single call when simply
reading the log file without the cache. The one disadvantage of using a cache is that the log file is
not updated in real-time, only after a call has completed. Should there be a desire to have the logs
updated immediately after the events occur, then caching should be left out of the configuration.
The
<cache>
tag has only one child tag:
<per_call>
, indicating that the cache’s lifetime is a
single call to an application.
<per_call>
defines two attributes:
kb_limit
, an integer value
greater than 0 that defines the size of the cache in kilobytes, and
allocate
that defines the cache
allocation strategy. The attribute can be set to two different values:
once
. The Activity Logger will allocate the full memory needed for the cache once and then
fill it up with logging information. When filled, the cache is flushed to the log file and the
same section of memory is cleared and then refilled.
same section of memory is cleared and then refilled.
as_needed
. The Activity Logger will allocate memory as events arrive in the call until the
total amount of memory has been allocated. When it is to be flushed, the memory is released
and then the allocation begins again.
and then the allocation begins again.
The advantage of allocating the memory at once is that since a contiguous section of memory is
being used, the updating, maintenance, and flushing of that memory will be slightly faster.
Additionally, with only one area of memory per call less memory allocations take place, which
can affect how often Java garbage collection runs. A disadvantage is that the cache size should
be chosen carefully. Too small a cache will incur performance hits as the cache fills up and is
logged multiple times within a call. Too large a cache would mean that a large amount of
memory is allocated and then never used, potentially starving the rest of the system. A good
cache size would be approximately the size of a log for a typical call to the application. Since the
cache is flushed at the end of a call, there is little reason to make the cache much larger.
being used, the updating, maintenance, and flushing of that memory will be slightly faster.
Additionally, with only one area of memory per call less memory allocations take place, which
can affect how often Java garbage collection runs. A disadvantage is that the cache size should
be chosen carefully. Too small a cache will incur performance hits as the cache fills up and is
logged multiple times within a call. Too large a cache would mean that a large amount of
memory is allocated and then never used, potentially starving the rest of the system. A good
cache size would be approximately the size of a log for a typical call to the application. Since the
cache is flushed at the end of a call, there is little reason to make the cache much larger.
The advantage to allocating the memory as needed is that this minimizes the memory used since
only the memory needed to store the information is used. The cache size is not as important, and
making it larger will not affect the overall memory usage as drastically as if the cache was
allocated all at once since the memory would not be allocated unless needed.
only the memory needed to store the information is used. The cache size is not as important, and
making it larger will not affect the overall memory usage as drastically as if the cache was
allocated all at once since the memory would not be allocated unless needed.