The time has come to say some words about dynamic script and how it can kill the performance of your MSS deployment. First an overview of the general problem:

JScript.NET is at the heart of MSS 2004 applications. Some of it is generated by ASP.Net and tons of it is generated by MSS Speech Controls too. You've probably had to write loads for your prompt functions and client-side behavior. You just can't get away from it. (Fortunately you can in MSS 2006.)

MSS deals with this script in a wonderfully fast and efficient manner - it compiles each web page of script to a .Net assembly. This has the following advantages:

  • Security: MSS can sandbox applications from each other and limit what they can do using .Net Code Access Security.
  • Scalability: Compiled JScript consumes less CPU than interpreted JScript, allowing one box to support more ports.
  • Efficiency: As long as the script on a web page doesn't change, the assembly only needs to be compiled once and can be shared amongst applications.

Ah, but what happens when the script does change each time MSS downloads the page? I'm no ASP.Net expert but I believe you can do stuff like this:

<script>window.alert("<% Response.Write(new Random().Next(1,10).ToString()); %>");</script>

This might be okay for Internet Explorer, which does no caching and interprets everything. This is not so good for MSS, for the simple reason that the .Net Framework does not allow you to unload an assembly once it's loaded. So if the script is subtlely different each time it is downloaded MSS will compile it to a new assembly and then be stuck with that assembly until the AppDomain or TasWorker is recycled. The first sign of trouble is usually unexpected process recycles - since these are automatically triggered by memory consumption over a certain threshold. You will also see increased latencies since you are incurring the cost of compilation for each page navigation - something which usually seems to happen when the end user is waiting for a response. Note that MSS 2004 R2 will detect dynamic script problems and write an event to the NT Event Log.

The good news is that there are ways and means to avoid this issue. The number one fact to take advantage of is that MSS does not cache the Document Object Model  (i.e. everything on the page that isn't script.) Hence the above fragment can be rewritten as:

<div id="random" number="<% Response.Write(new Random().Next(1,10).ToString()); %>"/>

<script>window.alert(random.number);</script>

Since the script is now static different instances of the page will share the same assembly. At run time the application gets the value to display from the DOM.

[Side note: What is and what isn't script? Clearly everything within <script> blocks is script, as well as files referenced by <script src=.../>. For the purposes of this discussion, stuff inside 'id' attributes is also considered script, i.e. if you change the id of an element you are changing the assembly that the page compiles to. Event handlers are also script, e.g. <body onload="thisIsScript()"> <salt:dtmf onreco="moreScript()">]

That's probably enough of an overview. Next I'm going to talk about some general strategies for dealing with dynamic script and some specific gotchas to do with the Speech Controls.