Eliminate Dynamic Scripting in SALT Voice Response Applications
This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.
Using dynamic scripting in SALT (Speech Application Language Tags) voice response applications leads to increased memory consumption and a loss of scalability and performance. To avoid these issues, eliminate dynamic scripting from SALT voice response applications. The following sections provide a thorough exploration of the negative impacts that can result from dynamic scripting.
Performance Impact of Script Compilation
Speech Server downloads speech application Web pages from the Web server. From the downloaded Web pages, Speech Server creates a Document Object Model, concatenates all script blocks, and compiles them into a single script blob. Aside from the computational cost of compiling the script, each compilation requires memory, which is only released on the next application domain or process recycle, even if the script is never used again. So, unless Speech Server stops compiling script or a recycle occurs, Speech Server ultimately runs out of memory. In this context, if the system meets the hardware requirements for Speech Server, running out of memory means running out of virtual address space. By default, the virtual address space is 2??GB on 32-bit systems.
In the worst case, for example compiling script for every page download and using the default configuration for Speech Server, this can cause any of the following symptoms:
- Frequent process recycles, which only occurs if the Maximum used memory option is selected for the Speech Server application pool in Internet Information Services (IIS) Manager. This option is not selected by default. For more information, see Configure Application Pool Recycling (IIS 6.0).
- Periods of time where some or all calls encounter dead air, or disconnect.
- A sudden restart of W3wp.exe (the application pool), resulting in loss of all existing calls followed immediately by normal service when the new W3wp.exe is running.
The first symptom in the preceding list is a mechanism used to prevent a total loss of memory and to keep the system functioning. In the worst case, the process recycles cannot happen frequently enough to keep up with the memory growth, which causes the other symptoms to appear. When the second symptom occurs, the application event log contains several error messages, such as time-outs or out of memory errors. When the final symptom occurs, there is a single error followed by an information message indicating that the new process is started.
If script compilations are not frequent enough to trigger this worst-case behavior, the impact is limited to the consumption of CPU cycles used to perform the compilation, plus a potential negative impact on other processes (for example, Speech Engine Services in an all-in-one configuration, due to a decreasing amount of available RAM).
Caching Compiled Script Blobs
To avoid recompilation of static script, Speech Server caches the compiled script blob for later reuse. The caching algorithm is based on the content of the page and the concatenated script blocks. As a result, if the content of the script block is static for a Web page, the cache is used when the same page is reloaded (for example, for a new telephone call to the system).
In this way a speech application that always returns exactly the same script for each Web page benefits from the cache and does not suffer any of the described problems. Dynamic script refers to the case where an application always returns a different script for a given Web page. In this case, the cache cannot be used and Speech Server suffers the described problems.
Speech Server does allow several variants for each Web page; however, if the number of variants is exceeded, the benefits of the cache are lost. The exact number of variants allowed depends on several factors. However, if the number of variants is exceeded, the end result is the same as if dynamic script is present.
How to Detect Dynamic Script
A script compilation for each page in an application is expected in the following cases:
- After startup
- Following an application domain recycle
- Following a process recycle
When script compilation occurs more often, it indicates that the page contains some dynamic script content. In this case, the administrator should inform the author that the page is not being cached properly, apparently because it contains dynamic script content.
Speech Server provides performance counters that allow an administrator to monitor the performance of the server. The SpeechService\SALT Script Compilations performance counter measures the total number of times application script required compilation since the service was started. This counter is incremented only for successful compilations.
To locate dynamic script in application files, it might be useful to monitor Event Viewer for Event ID 534, with the following text:
The SALT interpreter detected dynamic script content for the following URI: <URI of the page containing the dynamic script>. To identify the dynamic content, review the versions of the script <a list of files, for example, tas2C.js tas2D.js tas2E.js tas2F.js> that were saved to: < file path>. These files will be deleted during the next application domain recycle.
Look at the JScript (.js) files listed in the event text to see which parts of the application might be dynamic.
An Example of Dynamic Script
A page contains dynamic content if the content of either the script or HTML changes each time the page loads. Dynamic content within HTML is not a problem; however, dynamic content within script blocks, called dynamic script, can be a problem. Dynamic script can force the Speech Application Language Tags (SALT) interpreter to recompile the concatenated script blocks every time the page is downloaded. The following code fragment is an example of dynamic script.
<SCRIPT> var userName = <% Response.Write Request.QueryString("name") %> </SCRIPT>
Speech Server allows several script variants per page to cope with server-side transfers. Because this limit is affected by the number of controls on the page, modifying the Enabled property of Speech Controls might affect the Speech Server caching ability.
Solutions
The best solution is to simply remove dynamic scripting. It might be possible to do this through the use of DIV elements, as described in the next section. If necessary, consider using process recycles, as described later in the "Further Steps" section.
Move Dynamic Content Inside DIV Elements
To optimize production server performance, avoid creating dynamic content. The following example shows how the same functionality in the previous code fragment can be rewritten (through use of the DIV element) so the script block does not contain dynamic content.
<DIV id="userNameElement"><% Response.Write Request.QueryString("name") > </DIV>
<SCRIPT> var userName = userNameElement.innerText; </SCRIPT>
Further Steps
The first step is to observe the system under load. If there are no observable effects to callers then no further action is necessary. If callers are affected (for example. there are errors in the event log), then use the following procedure to ensure that the Speech Server application pool configuration settings trigger process recycles at the correct time and therefore prevent Telephony Application Host from running out of virtual address space.
To reduce the maximum address space consumed by Telephony Application Host
Ensure that the IIS shutdown time limit value and ASP ShutdownTimeout value are set appropriately.
The value should be long enough for the longest expected reasonable call duration.
Review the NT System event log for messages from W3SVC with ID 1077 and text such as "A worker process with process ID of '5096' serving application pool Speech Server has requested a recycle because it reached its virtual memory limit".
Measure the time between these events for the application-pool hosting your application (by default this is Speech Server).
If this measured time is more than the shutdown time-out, use IIS Manager to lower the maximum virtual memory for the application pool so that process recycles occur more frequently.
To determine the lower bound, observe the Microsoft Windows Server 2003 "Process (w3wp)\Virtual Bytes" performance counter prior to any incoming calls.
If this measured time is less than the shutdown time-out, it is not possible to recycle the process fast enough.
Conclusion
Changing the Enabled property of Speech Controls or placing dynamic content in a script block forces Speech Server to recompile Web pages, rather than using the cache. This leads to increased memory consumption and a loss of scalability and performance. To avoid problems resulting from excessive page compilations, eliminate dynamic script from SALT voice response applications.