The supported
capacity for MediaSense is a function of the hardware profile that the system
selects at startup time. The hardware profile depends on which VM template the
node is deployed on, and the VM template depends partially on what type of
hardware you are deploying. (See
Virtual Machine Configuration
for a full description of each template.) The
Hardware Profiles
section shows the actual capacity when using each type of VM template.
For example, for
each 7 vCPU template node (the standard for large production deployments) the
MediaSense server supports up to 400 media streams simultaneously (200 calls)
at a sustained busy hour call arrival rate of two calls per second on up to 12
terabytes of disk space. The 400 represents all streams used for recording,
live monitoring, playback, .mp4 or .wav conversion, and HTTP download; all of
which may occur in any combination. Conversion and download are not
specifically streaming activities, but they do use system resources in a
similar way and are considered to have equal weight. Playback of a video track
takes 9 times more resources than playback of an audio track. As a result, each
uploaded video playback (one video track plus one audio track) has the weight
of 10 audio tracks, leading to a maximum capacity of 40 simultaneous video
playbacks per node.
In determining how
many streams are in use at any given time, you need to predict the number of
onsets for each activity per unit time as well as their durations. Recording,
live monitoring, and playback have a duration that is equal to the length of
the recording. Video playbacks, if configured to play once only, have a
duration equal to the length of the video. Video playbacks for hold purposes
must be estimated to last as long as each video caller typically remains on
hold. The .mp4 conversions, .wav conversions, and HTTP download durations are
estimated at about 5 seconds per minute of recording.
To determine the
number of servers required, evaluate this data:
-
The number simultaneous
audio streams needed plus 10 times the number of videos being played, divided
by the number of audio-weight media streams supported by each node
-
The number of busy hour
call arrivals divided by the maximum call arrival rate for each node
-
The space required for
retained recording sessions divided by the maximum media storage for each node.
The number of
servers required is equal to the largest of the above three evaluations
(rounded up).
Video playback for
VoH, ViQ, and video messaging is further limited on 2\- and 4-vCPU virtual
hardware and depends on the type of physical hardware being used. See
Hardware Profiles
for details.
Another factor
that significantly impacts performance is the number of MediaSense API requests
in progress. This is limited to 15 at a time for 7-vCPU systems, with the
capability to queue up to 10 more (the numbers are reduced for smaller
systems). These numbers are per node, but they can be doubled for MediaSense
clusters that contain both a primary and a secondary node. For more
information, see
System Resiliency and Overload Throttling.
The media output
and conversion operations (monitoring, playback, convert to MP4 or WAV, and
HTTP download) are entirely under client control. The client enforces its own
limits in these areas. The remaining operations (call recording and uploaded
media file playback) are not under client control. The deployment can be sized
so that the overall recording and video playback load will not exceed a desired
maximum number cluster-wide (allowing for an enforceable number of monitoring,
playback, and HTTP download operations). The recording and video playback load
is balanced across all servers. (Perfect balance will not always be achieved,
but each server has enough room to accommodate most disparities.)