Avoiding Dynamic Scripts

Telephony Application Services (TAS) downloads SDK speech application web pages from the Web server. From the downloaded Web page TAS creates a document object model and also concatenates all script blocks and compiles this into a single compiled script blob. Compiled script blobs are cached for later use, since compilation is computationally expensive for the production server. The script compilation caching algorithm is based on the content of the page and the concatenated script blocks. As a result, if the script blocks' content is static for a web page, then when the same page is re-loaded (for example, for a new telephone call to the system) the cache is used, which saves an expensive compilation step. Using the cache in this way leads to reduced memory consumption, and improved performance and scalability on TAS.

Applications with Dynamic Content

A page contains dynamic content if the content changes each time the page is loaded, for example if the content of the script block changes. The caching mechanism breaks down when dynamic content is present. With dynamic content the SALT interpreter is forced to recompile the concatenated script blocks every time the page is downloaded. Changing any properties on a QA control on the server during a postback, for example changing the Enabled property, can cause the page script to be recompiled. Also, page script is recompiled if dynamic content is entered into a script block, as in the following example.

<SCRIPT>
    var userName = <% Response.Write Request.QueryString("name") %>
</SCRIPT>

To optimize production server performance avoid creating dynamic content. The following example shows how the same functionality in the previous example can be rewritten without the script block containing any dynamic content, through use of the DIV element.

<DIV id="userNameElement">
    <% Response.Write Request.QueryString("name") >
</DIV>
<SCRIPT>
    var userName = userNameElement.innerText;
</SCRIPT>

Detecting Dynamic Content

Speech Server provides performance counters which allow an administrator to monitor the performance of the server. The TAS Script Compilation 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. In general, script compilation should occur only the first time a page is loaded, or during an application domain recycle. If the counter continues to increase with telephone calls into the system, it indicates that script on one of the application pages contains dynamic content. The administrator can narrow this down further by looking at the trace logs for a Log.Trace event, where the message indicates that the ScriptCache requires a new slot (or compilation). In the following example a new script compilation is required for the page http://WebServerMachine/MyApp/page3.aspx.

Microsoft.SpeechServer.Log.Trace
{
   String Message = "ScriptCache: New cookie='229'"
   String ExceptionDetails = ""
   Int32 ProcessID = 4160
   WindowsSecurityInfo WindowsSecurity = null
   ManagedSecurityInfo ManagedSecurity = null
   String StackTrace = ""
   String ServiceProvider = "InboundSaltApplication0_24"
   Int32 EventLogEntryTypeID = 4
   Int64 EventSequenceNumber = 107060
   String EventSourceInstance = "6c76c5b6-c1d6-40ef-a0d1-ecd039489664"
   String EventSourceName = "Application"
   String MachineName = "TAS_Machine"
   DateTime TimeStamp = 9/12/2003 20:27:01.518
   SpeechContext SpeechContext = {
      String ApplicationInstance = "81868C3D-76DD-4C9B-BA4F-37FAA6D7F663"
      String PageUri = "http://WebServerMachine/MyApp/page3.aspx"
      String RequestID = null
   }
}

A script compilation is expected the first time this page is loaded, after start up, or following an application domain recycle or a TAS worker recycle. However if script compilation occurs more often it indicates that the page contains some dynamic script content. The administrator should inform the application developer that the page is not being cached properly, apparently because it contains dynamic script content.

Using Configuration Changes to Alleviate Memory Pressure

It is conceivable that there may be occasions where a workaround is not feasible, and that the application still contains dynamic script content. As well as some performance and/or scalability degradation, this will lead to greater virtual memory consumption as more cache slots will be used. If this is the case, unscheduled TAS recycles may occur because virtual memory is exceeded.

To alleviate the memory pressure caused by dynamic script content, administrators should decrease the RecycleCallLimit WMI property. For information on TAS recycle settings see the topic Defining Telephony Application Services Optimization Settings in Speech Server Help. The RecycleCallLimit property causes an application domain recycle whenever the number of calls reaches the specified number. An application domain recycle resets the SALT interpreter's managed heap, cleaning up virtual memory consumption. Causing application domain recycles to occur at a more predictable regular interval is more advisable than relying on unscheduled TAS worker process recycles since the memory pressure problem is likely to increase while the process recycle is in progress.

Note that application domain recycles are compute-intensive, and will lead to increased user latency. Administrators should continue to do what they can to persuade application developers to remove dynamic script content.

See Also

Deploying Speech Applications | Authoring Notes | Using Telephony Application Services