Contents
[hide]VoIP Capacity Testing
This is a sub-topic of Traffic and Capacity Testing!
The complexity of VoiceXML and CCXML applications impacts capacity testing, therefore, the Genesys QA performance testing results in this section are derived from test cases using four different VoiceXML applications and two different CCXML applications (some more complex than others).
VoiceXML Application Profiles
VoiceXML performance testing was conducted on four major application profiles. Their characteristics are outlined in Table 135. The call flow duration for each application profile is for a single call or CD1 (see “Call Duration and Peak Capacity” on page 292).
Table 135: VoiceXML Test Application Profiles
| Column 1 Heading | Column 2 Heading |
|---|---|
| text | text |
| text | text |
CCXML Application Profiles
CallControlXML (CCXML) performance testing was conducted on two major application profiles. Their characteristics are outlined in Table 136. The call flow duration for each application profile is for a single call or CD1 (see “Call Duration and Peak Capacity” on page 292).
Table 136: CCXML Test Application Profiles
| Column 1 Heading | Column 2 Heading |
|---|---|
| text | text |
| text | text |
VoIP Capacity Summaries
Some capacity test summaries in this section were performed on systems with hardware specifications other than those recommended in Table 133 on page 292. Major differences in test results can occur, depending on the CPU model and the number of CPUs that are used.
VoiceXML_App3 was used for both single server testing and PSTNC testing. See Table 139, “Single Server All-In-One Capacity Testing,” on page 306 and PSTNC Table 145, “PSTN Connector and SSG Capacity Testing,” on page 338.
How to Use These Tables
How does a reader approach the difficult task of sizing, in the face of so much raw data contained by the tables in the following section? Each table is prefaced with a description of its intent, and suggestions for interpreting and applying the data.
Click on a link in the list below, and find specific details about intent and use above each table:
- Table 137, “GVP VOIP VXML/CCXML Capacity Testing,” on page 300
- Table 138, “Multiple VMs Versus Multiple MCP Capacity Testing,” on page 302
- Table 139, “Single Server All-In-One Capacity Testing,” on page 306
- Table 140, “Media Control Platform Capacity Testing (Physical Servers),” on page 308Table 140, “Media Control Platform Capacity Testing (Physical Servers),” on page 308
- Table 141, “Media Control Platform / Media Server Capacity (Virtual Servers),” on page 313
- Table 142, “Resource Manager and MRCP Proxy Capacity Testing,” on page 323
- Table 143, “Reporting Server Capacity Testing,” on page 330
- Table 144, “CTI Connector with IVRSC and CTI Connector with ICM Capacity Testing,” on page 332
- Table 145, “PSTN Connector and SSG Capacity Testing,” on page 338
GVP VOIP Capacity Testing
Table 137: GVP VOIP VXML/CCXML Capacity Testing shows the fundamental performance of a single physical server process in terms of peak throughput and peak port capacity, either VoiceXML applications for MCP or CCXML for CCP. You can use this table as the first basis of your assessment.
| Column 1 Heading | Column 2 Heading |
|---|---|
| text | text |
| text | text |
Multiple VMs Versus Multiple MCP Capacity Testing
Table 138: Multiple VMs Versus Multiple MCP Capacity Testing provides a comparison of capacity testing results when multiple virtual machines (VMs) are used versus multiple Media Control Platform instances.
This table shows the effect of stacking server processes on the same hardware server where there is one MCP associated with a VM instance on the same hardware server. The effect is the increased total port capacity that you can achieve using stacked processes. provides a comparison of capacity testing results when multiple virtual machines (VMs) are used versus multiple Media Control Platform instances.
This table shows the effect of stacking server processes on the same hardware server where there is one MCP associated with a VM instance on the same hardware server. The effect is the increased total port capacity that you can achieve using stacked processes.
| Column 1 Heading | Column 2 Heading |
|---|---|
| text | text |
| text | text |
Single Server All-In-One Capacity Testing
Table 139: Single Server All-In-One Capacity Testing describes the capacity testing for single server with multiple components installed (see comments column). Tests were performed by using a single instance of the Media Control Platform on Windows and Linux systems with 1 Core 2 Dual Xeon x5160, 3.0 GHz CPUs with 8 GB RAM. This table shows the effect of having many GVP processes, including Nuance speech components, on just one physical server, which Genesys calls “the single server solution.
| Column 1 Heading | Column 2 Heading |
|---|---|
| text | text |
| text | text |
Component Capacity Test Cases
This section describes capacity test case results for the GVP components and includes the following tables:
- Media Control Platform / Media Server Capacity (Physical Servers)—Table 140 on page 308
- Media Control Platform / Media Server Capacity (Virtual Servers)—Table 141 on page 313
- Resource Manager—Table 142 on page 323
- MRCP Proxy—Table 142 on page 323
- Reporting Server—Table 143 on page 330
- CTI Connector—Table 144 on page 332
- CTI Connector/ICM—Table 144 on page 332
- PSTN Connector—Table 145 on page 338
- Supplementary Services Gateway—Table 145 on page 338
or additional sizing information for Genesys Media Server with SIP Server, see See Chapter 18, “Genesys Administrator,” page 503 of this guide. The capacity testing results for the Media Control Platform are described in Table 140 on page 308. Tests were performed by using a single instance of the Media Control Platform on Windows and Linux systems with 2x Core 2 Quad, Xeon x5355, 2.66 GHz CPUs.
NOTE: Media Services Only: If your deployment is limited to Media Services, then see critical information for sizing the MCP in Table 140, “Media Control Platform Capacity Testing (Physical Servers),” on page 308 and the section “Genesys Media Server Sizing with SIP Server” in the SIP Server Sizing Guide.
Media Services plus VoiceXML Applications: If you have both types of services on the same GVP system, media and VoiceXML, then the actual performance will be a roughly proportional combination of media service performance and VoiceXML performance. This will be rather difficult to determine. We recommend that you default to the media performance metrics if transcoding is prevalent or media services are significant.
Media Control Platform Capacity Testing
Table 140: Media Control Platform Capacity Testing does not focus on GVP as a whole, but rather shows the impact of media services (announcements, call parking, bridging, conferencing, transcoding and video) on the performance of the Media Control Platform (MCP).
| Column 1 Heading | Column 2 Heading |
|---|---|
| text | text |
| text | text |
Media Control Platform / Media Server Capacity (Virtual Servers)
Table 141: Media Control Platform / Media Server Capacity (Virtual Servers)
| Column 1 Heading | Column 2 Heading |
|---|---|
| text | text |
| text | text |
Resource Manager and MRCP Proxy Capacity Testing
Table 142: Resource Manager and MRCP Proxy Capacity Testing describes the capacity testing for overall system performance when the Resource Manager and MRCP Proxy (Windows only) are tested with multiple Media Control Platform instances.
| Column 1 Heading | Column 2 Heading |
|---|---|
| text | text |
| text | text |
Reporting Server Capacity Testing
Table 143: Reporting Server Capacity Testing describes the capacity testing for overall system performance when the Reporting Server is tested with multiple Media Control Platform instances.
Tables 143, 144 and 145 show the performance of other GVP components individually. Use these tables to see determine if you encountered any performance limits beyond those already defined in Table 137 through Table 142. Use these tables if you are interested in determining the overall system limits, which may occur in VoiceXML, media services, reporting, RM, or other functions.
| Column 1 Heading | Column 2 Heading |
|---|---|
| text | text |
| text | text |
CTI Connector and CTI Connector with ICM Capacity Testing
Table 144: CTI Connector and CTI Connector with ICM Capacity Testing describes the capacity testing for overall system performance when the CTI Connector is tested with multiple Media Control Platform instances. Results are provided for CTI applications and treatments using both GVPi and the NGI. In addition, CPUs of varying types and speeds were used for testing on Windows, and are specified for each application.
| Column 1 Heading | Column 2 Heading |
|---|---|
| text | text |
| text | text |
PSTN Connector and SSG Capacity Testing
Table 145: PSTN Connector and SSG Capacity Testing describes the capacity testing for overall system performance when the PSTN Connector or Supplementary Services Gateway components are tested with multiple Media Control Platform instances. In addition, CPUs of varying types and speeds were used for testing on Windows, and are specified for each application.
| Column 1 Heading | Column 2 Heading |
|---|---|
| text | text |
| text | text |
Call Setup Latency Test Cases
In the following test cases, maximum capacity was achieved within the constraints of specific thresholds. However, the system was also tested beyond the recommended capacity to determine the extent of performance degradation.
The test case in Figure 106 uses the VoiceXML_App1 profile (in Table 135 on page 296) to show how the CSL increases as the PD increases. The rate at which the CSL increases is relatively constant until the system reaches a bottleneck—for example, when the system load is beyond peak capacity.
File:PD Versus CSL Caller Perceived Latency Test Case The graph in Figure 107 shows the DTMF response-to-audio-prompt latency at various port densities (relative to the peak capacity indicated in Table 137 on page 300). Notice that the TTS prompts produce ~300 ms more latency than the audio file prompts. This is due to the beginning silence played by the TTS engine.
File:PD Versus DTMF
When there is speech input, additional latency is usually caused by the ASR engine. In Figure 108, the latency result is from 1000 words of grammar using the Nuance OSR3 MRCP version 1 (MRCPv1) engine. The result can vary, depending on the type of MRCP engine used, the type of speech grammar used, and the load on the speech engine.
The performance results in Figure 108 were obtained from isolated ASR engines supporting the same number of recognition sessions at all Media Control Platform port densities; the MRCP engines did not cause a bottleneck. Therefore, depending on the load on the Media Control Platform, it can add as much as ~100 ms of latency.
Cachable VoiceXML Content Test Cases
In the following test cases, maximum capacity was achieved within the constraints of specific thresholds. However, the system was also tested beyond the recommended capacity to determine the extent of performance degradation.
GVP can cache internal, compiled VoiceXML objects. Caching VoiceXML objects saves a significant amount of compilation time, which results in less CPU consumption. The VoiceXML_App1 application is used for the test case in Figure 109 and is based on the peak capacity indicated in Table 137 on page 300.
File:PD Versus CPU (VoiceXML App1)
The more complex the VoiceXML content, the greater the benefit of having cachable content. The test case in Figure 110 is similar to the one in Figure 109 except the more complex VoiceXML_App2 application is used (see Table 135 on page 296).
File:PD Versus CPU (VoiceXML App2)
In Figures 109 and 110 the processing of cachable and non-cachable content are compared with the Media Control Platform using the same level of CPU consumption for both applications. The following results clearly show the benefits of using cachable content:
CPU consumption—Media Control Platform at peak capacity:
- 15% less consumption than non-cached content using VoiceXML_App1.
- ~30% less consumption than non-cached content using VoiceXML_App2.
Port density—CPU consumption at same level for both applications:
- ~30-35% greater than non-cached content using VoiceXML_App1,
- ~50% greater than non-cached content using VoiceXML_App2.