Fabulous Adventures In Coding : ASP

It Already Is A Scripting Language

Eric Lippert — Wed, 24 Jun 2009 18:07:00 GMT

My recent post about the possibility of considering maybe someday perhaps adding "top level" methods to C# in order to better enable "scripty" scenarios generated a surprising amount of immediate emphatic pushback. Check out the comments to see what I mean.

Two things immediately come to mind.

First off, the suggestion made by a significant number of the commenters is "instead of allowing top-level methods, strengthen the using directive." That is, if you said "using System.Math;" then all the static members of that class could be used without qualification.

Though that is a perfectly reasonable idea that is requested frequently, it does not actually address the problem that top-level methods solve. A better "using" makes things easier for the developer writing the call. The point of top-level methods for scripty scenarios is to make it easier on the developer writing the declaration. The point is to eliminate the "ritual" of declaring an unnecessary class solely to act as a container for code.

Second, and more generally, I am surprised by this pushback because of course C# already is a scripting language, and has had this feature for almost a decade. Does this code fragment look familiar?

<%@ Page Language="C#" %>
<script runat="server">
void Page_Load(object sender, EventArgs e)
  {
      // whatever
  }
</script>
...

Where's the class? Where are the using directives that allow "EventArgs" to be used without qualification? Where's the code that adds this method group to the event's delegate? All the ritual seems to have been eliminated somehow. That sure looks like a "top-level method" to me.

Of course we know that behind the scenes it isn't any such thing. ASP.NET does textual transformations on the page to generate a class file. And of course, we recommend that you use the "code behind" technique to make a file that actually contains the methods in the context of an explicit (partial) page class, to emphasize that yes, this is a class-based approach to server-side processing.

But you certainly do not have to use "code behind". If you're an ASP traditionalist (like me!) and would rather see C# as a "scripting language" that "scripts" the creation of content on a web server, you go right ahead. You can put your "top level" methods in "script" blocks and your "top level" statements in "<% %>" blocks and you'll thereby avoid the ritual of having to be explicit about the containers for those code elements. The ASP.NET code automatically reorganizes your "script" code into something that the C# compiler can deal with, adding all the boring boilerplate code that has to be there to keep the compiler happy.

But consider now the burden placed upon the developers of ASP.NET by the language design. Those guys cannot simply parse out the C# text and hand it to the C# compiler. They've got to have a solid understanding of what the legal code container topologies are, and jump through hoops -- not particularly difficult hoops, but hoops nevertheless -- to generate a class that can actually be compiled and executed.

This same burden is placed upon every developer who would like to expose the ability to add execution of end-user-supplied code to their application, whether that's in the form of adding extensibility via scripting, or by enabling evaluation of user-supplied expressions (such as queries). It's a burden placed on developers of productivity tools, like Jon Skeet's "snippet compiler", or LINQPad. It's a burden on developers who wish to experiment with REPL-like approaches to rapid development of prototypes, test cases, and so on.

I am not particularly excited about the convenience of the ability to save five characters by eliding the "Math." when trying to calculate a cosine. The exciting value props are that we might be able to lower the cost of building tools that extend the power of the C# language into third-party applications, and at the same time enable new ways to rapidly experiment and develop high-quality code.

Of course we do not want to wreck the existing value props of the language in doing so; as I said last time, we also believe that there is huge value in the language design naturally leading professional, large-scale application developers towards building well-factored component-based programs.

Like all design decisions, when we're faced with a number of competing, compelling, valuable and noncompossible ideas, we've got to find a workable compromise. We don't do that except by considering all the possibilites, which is what we're doing in this case.

How To Obtain The Name Of The Client From The ASP Server

Eric Lippert — Mon, 09 May 2005 22:18:00 GMT

Here's a question about client side vs. server side scripting that I got recently:

I want to get the machine name of the client the request is being made from. With ASP I can get the IP address using this code: ipaddr = Request.ServerVariables("REMOTE_ADDR") But I don’t know how to get the name of the machine. Is there something I could do from the client side?

No, the web browser client cannot determine the name of the machine for two reasons.

First, if it could then the client could be instructed to send the name of the machine to an evil server. Evil hackers would love to have an internet web page that harvested intranet machine names that they could then attack. Knowing the name of a machine is particularly useful for social engineering attacks -- if someone phoned me up claiming to be from our IT department, I'd be a lot more inclined to believe them if they knew the names of all my machines.

Second, look at it from the other way. Suppose the client magically figures out its name and sends it to the server. Why should the server trust the client? What stops an evil client from sending a bogus name to the server? Even if the client could send the name, the server can't make any decisions based on that name, so it's kind of useless.

Clients and servers should not trust each other. In the absence of authentication evidence, clients must assume that all servers are run by evil hackers and servers must assume that all clients are run by evil hackers. Once you accept that fundamental design principle then it becomes much easier to reason about client-server interactions. Think like an evil person!

Another developer who saw this question suggested running this code on the server:

name = Request.ServerVariables("REMOTE_HOST")

That's a good start but not the whole story. By default this doesn't actually give you the remote host -- it just gives you the IP address again. If you want this to actually give you the name of the remote machine then there's some additional work you have to do. Since we have the IP address then we can do a reverse DNS lookup to see if there is a friendly name associated with that address. Now the server is trusting not an arbitrarty client but rather a specific reverse DNS server.

Read this Knowledge Base article on how to configure your server to automatically do Reverse DNS lookups when the code above is called.

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q245574

Note that this will make your server performance worse, and of course is not guaranteed to work if the client machine is disguising its identity via a firewall, etc.

What's the Difference between WScript.CreateObject, Server.CreateObject and CreateObject?

Eric Lippert — Tue, 01 Jun 2004 18:49:00 GMT

A reader asked me last week

I have always used Server.CreateObject in ASP scripts and WScript.CreateObject in WSH scripts, because I was unable to find any *convincing* information on the subject and therefore assumed that they were there to be used, and were in some way beneficial... but perhaps they're not?!

What exactly is the reasoning behind having additional CreateObjectmethods in ASP and WSH when VBScript already has CreateObject and JScript already has new ActiveXObject ? (new ActiveXObject is for all intents and purposes identical to CreateObject, so I'll just talk about VBScript's CreateObject for the rest of this article.) There are two reasons:

1) VBScript and JScript aren't the only game in town. What if there is a third party language which (inexplicably) lacks the ability to create ActiveX objects? It would be nice to be able to create objects in such a language, thus the hosts expose said ability on their object models. (Similarly, IE, WSH and ASP all have "static" object tags as well.)

Of course, this is a pretty silly reason. First off, no such language comes to mind, and second, why stop at object creation? A language might not have a method that concatenates strings, but that doesn't mean that we should add one to WSH just because it comes in handy. We need a better justification.

2) The ASP and WSH versions of CreateObject are subtly different than the VBScript/JScript versions because they have more information about the host than the language engine posesses. The differences are as follows:

WScript.CreateObject with one argument is pretty much identical to CreateObject with one argument. But with two arguments, they're completely different. The second argument to CreateObject creates an object on a remote server via DCOM. The second argument to WScript.CreateObject creates a local object and hooks up its event handlers.

Sub Bar_Frobbed()
WScript.Echo "Help, I've been frobbed!"
End Sub
Set foo = CreateObject("Renuberator", "Accounting")
Set bar = WScript.CreateObject("Frobnicator", "Bar_")

This creates a renuberator on the accounting server, a frobnicator on the local machine, and hooks up the frobnicator's events to functions that begin with the particular prefix.

Remember, in the script engine model the control over how event binding works is controlled by the host, not by the language. Both IE and WSH have quite goofy event binding mechanisms for dynamically hooked up events -- IE uses a single-cast delegate model, WSH uses this weird thing with the string prefixes.

Server.CreateObject creates the object in a particular context, which is important when you are creating transactable objects. Windows Script Components, for example, are transactable objects. This means that, among other things, you can access the server object model directly from a WSC created with Server.CreateObject , because the object obtains the server context when it is created. Ordinary CreateObject has no idea what the current page context is, so it is unable to create transactable objects. There are many interesting facets of transactable objects which I know very little about, such as how statefulness and transactability interact, how the object lifetime works and so on. Find someone who writes a blog on advanced ASP techniques and ask them how it works, because I sure don't know.

I'll answer the question "what's the difference between WScript.CreateObject and WScript.ConnectObject?" in a later blog entry.

I answered the question "What's the difference between GetObject and CreateObject ?" in this blog entry.

VBScript and JScript Don't Mix, at least in ASP

Eric Lippert — Thu, 19 Feb 2004 18:48:00 GMT

A reader wrote me recently to describe a problem that I used to hear fairly often:

I write ASP code using VBScript and a coworker of mine uses JScript. We were wondering if we could combine our code in ASP. However, it does not seem to be working right. Here is an example of where we are having trouble:

<SCRIPT LANGUAGE="JScript" RUNAT="Server">
Response.Write("<H1>header</H1>");
</SCRIPT>
<SCRIPT LANGUAGE ="VBScript" RUNAT="Server">
Response.Write "<H1>body</H1>"
</SCRIPT>
<SCRIPT LANGUAGE ="JScript" RUNAT="Server">
Response.Write("<H1>footer</H1>");
</SCRIPT>

As you can see this code should write:

header
body
footer

but the ASP engine does not render it like that.

My advice: don't mix languages on one ASP page because, as my correspondent discovered, it doesn't work the way you think it should. The rendering comes all out of order. Why?

Before you read on, if you don't understand the ASP compilation model you should read my earlier post on the subject. To briefly recap, ASP translates the page into a script, sticks the script into an engine, and then clones the engine a bunch of times if it needs to. Every time the page is served, the engine is pulled out of the engine pool, the script is run, and everything just works.

So what happens when you have two languages on the page? You need two engines, but the mechanism is the same. The page is compiled up into two scripts, and ASP runs one engine and then the other.

Now it should become clear why this appears to run out of order. From ASP's perspective, the page above turns into two scripts:

// Jscript
Response.Write("<H1>header</H1>");
Response.Write("<H1>footer</H1>");

' VBScript
Response.Write "<H1>body</H1>"

The ASP engine does not maintain any information about which chunk should execute before another. It gathers up all the script chunks for each language, compiles them, and then runs each engine in turn. Not only does it lead to seemingly out-of-order execution as shown here, but it also restricts the language blocks from calling each other's methods (because the methods in the not-yet-executed block may not have been initialized yet.) A detailed discussion of how IE solves this problem deserves another blog entry on its own.

Mixing languages can also lead to performance problems, because it means that each page is now consuming TWO engines from the engine cache, which means more cache misses, larger working set, etc.

While I'm on the subject, note that it is in general a bad idea to put a whole lot of "inline" code into <SCRIPT> blocks like that. Ideally you want the server side <SCRIPT> blocks to contain only global function definitions, and the <% %> blocks to contain only "inline" code. ASP does not enforce that constraint, but ASP.NET does. (The reasoning behind that is long enough to require another post.)

If you really want to have multiple languages on one ASP page, here is a way you can make this work though if you really need to. You could write a bunch of Windows Script Component objects in different languages, which expose methods. You could then write an ASP page in one language that calls those methods in the right order. WSCs are good in ASP because (a) they efficiently cache engine state, just like ASP, and (b) they can use the ASP object model directly if you write them correctly.

The Tragedy of Thread Happiness Disease

Eric Lippert — Sun, 15 Feb 2004 19:46:00 GMT

A JOS reader interested in developing server software asked recently

Is it possible to determine the number of concurrent threads a server can support from the server's specification?

Now, as I've said before, I'm no expert on performance tuning multi-threaded applications, but I have picked up a thing or two hanging around the real experts on the IIS team. In fact, the perf teams get questions in this vein all the time from customers, both internal and external.

The interesting thing about the question is that it is symptomatic of Thread Happiness, a peculiar disease which usually strikes programmers who are relatively new to large-scale multi-threaded software development.

How do I know that the questioner is getting Thread Happy? Because if they were writing an application where there were two threads or five threads or ten threads then they wouldn't be asking that question. They'd be asking "I want to write a server app with two/five/ten/whatever threads -- how buff does the server have to be?"

But they're asking the question "how many threads can I create on a given server?" so I can only assume that they are thinking of writing some application that is going to create a large and variable number of threads, as many as possible.

That's Thread Happiness right there. Don't do that! It's almost certainly a bad design. Massively multi-threaded applications cause more problems than they solve; they are very difficult to get correct, and even harder to get performant.

To actually answer the question, no, there's no way of telling that from the server spec. Why? Because there is nowhere near enough information in the "static" facts about the hardware. Server application threading performance depends on "dynamic" facts like:

What other processes are going to be running?
What are those threads going to be doing?
How much memory do you have free?
How much contention, locking, busy waiting, context switching, blah blah blah, is there going to be?
What are the performance metrics that will determine when things have gotten too bad.

So, in short, don't even go there. Come up with a design that uses a small number of threads and tune that.

Now, you might be wondering "What about real-world server applications which do spin up a variable number of threads then? How do they decide how many is too many?"

It's quite hard. These things used to be configurable in IIS, but a few years back the IIS team had the realization that (a) you can't expect a human being to figure out what the ideal thread limit is, and (b) the ideal thread limit changes dynamically because of all the factors I mentioned above.

IIS therefore keeps a relatively small thread pool, and continually monitors its own performance, tweaking the thread pool count, thread priorities, etc, as conditions change. It tries to keep the server well-tuned dynamically.

This was non-trivial code to write. Though I've done quite a bit of optimization of software that runs in-process with IIS, the details of the IIS thread timing algorithms are way, way beyond my skills. I wouldn't recommend such an approach unless you've got a lot of experience in the field. A huge performance lab with a wide range of server hardware and a dedicated staff of experienced performance testers doesn't hurt either!

Speeding Can Slow You Down

Eric Lippert — Tue, 02 Dec 2003 01:35:00 GMT

I hope all you readers living in the United States had a restful and enjoyable Thanksgiving holiday. I sure did.

I've been meaning to talk a bit about some of the performance issues you run into when tuning massively multi-threaded applications, like the ASP engine. I'd like to start off by saying that I am by no means an expert in this field, but I have picked up a thing or two from the real experts on the ASP perf team over the years.

One of the most intriguing things about tuning multi-threaded applications is that making the code faster can slow it down. How is that possible? It certainly seems counter-intuitive, doesn't it?

Let me give you an analogy.

Suppose you have an unusual road system in your town. You have a square grid of roads with stoplights at the intersections. But unlike the real world, these are perfect traffic lights -- they are only red if there actually is another car in the intersection. Unlike a normal road, each road goes only one way, and has at most one car on it at a time. Once a car reaches the end of the road, it disappears and a new car may appear at the start. Furthermore, there is a small number of drivers -- typically one or two, but maybe eight or sixteen, but probably not one for every car. The drivers drive a car for a while, then stop it and run to the next car! The drivers are pretty smart -- if their car is stopped at a red stoplight then they'll run to a stopped car that is not at a red stoplight (if one exists) and drive it for a while.

In our analogy each road represents a thread and each stoplight represents a mutex. A mutex is a "mutually exclusive" section of code, also known as a "critical section". Only one thread can be executing in that code at one time. The car represents the position of the instruction counter in this thread. When the car reaches the end of the road, the task is finished -- the page is served. The drivers represent the processors, which give attention to one thread at a time and then context switch to another thread. The time spent running from car to car is the time required to perform a thread context switch.

Now imagine that you want to maximize the throughput of this system -- the total number of cars that reach the end of their road per hour. How do you do it? There are some "obvious" ways to do so:

hire more drivers (use more processors)
eliminate some stoplights by building overpasses at intersections (eliminate critical sections)
buy faster cars (use faster processors)
make the roads shorter (write pages that require less code)

You'll note that each of these is either expensive or difficult. Perf isn't easy!

Now, I said that these are "obvious" ways to solve this problem, and those scare quotes were intentional. Imagine a complex grid of roads with lots of stoplights, a moderate number of cars on the road, and two drivers. It is quite unlikely that cars will spend a lot of time stopped at stoplights -- mostly they'll just breeze right on through. But what happens when you throw another six drivers into the mix? Sure, more cars are being driven at any one time, but that means that the likelihood of congestion at stoplights just went up. Even though there are four times as many drivers, the additional time spent at stoplights means that the perf improvement is less than a factor of four. We say that such systems are not scalable.

Or consider a moderately congested freeway system with a whole lot of cars, drivers and intersections. Now suppose that you keep the cars, drivers and intersections the same, but you shrink the whole system down to half its previous size. You make all the roads shorter, so that instead of having eight stoplights to the mile, now you've got twenty. Does total throughput get better or worse? In a real traffic system, that would probably make things worse, and it can in web servers as well. The cars spend all their time at intersections waiting for a driver to run over to them. Making code faster sometimes makes performance worse because thread congestion and context switches could be the problem, not total path length.

Similarly, making the cars faster often doesn't help. In the real world of Seattle traffic, upgrading from my 140-or-so horsepower Miata to a 300 HP BMW isn't going to get me home any faster. Getting a faster processor and shorter program only helps if the "freeway" is clear of traffic. Otherwise, you sit there in your souped-up ultimate driving machine going zero at stoplights like everyone else. Raw power does not scale in a world with lots of critical sections.

When perf tuning servers, use the performance monitor to keep a careful eye on not just pages served per second, but on thread switches per second, processor utilization and so on. If you cannot saturate the processor and the number of thread switches is extremely high, then what is likely happening is that the drivers are spending way too much time running from car to car and not enough time actually driving. Clearly that's not good for perf. Tracking down and eliminating critical sections is often the key to improving perf in these scenarios.

Eval is Evil, Part Two

Eric Lippert — Tue, 04 Nov 2003 22:23:00 GMT

As I promised, more information on why eval is evil. (We once considered having T-shirts printed up that said "Eval is evil!" on one side and "Script happens!" on the other, but the PM's never managed to tear themselves away from their web browsing long enough to order them.)

Incidentally, a buddy of mine who is one of those senior web developer kinda guys back in Waterloo sent me an email yesterday saying "Hello, my name is Robert and I am an evalaholic". People, it wasn't my intention to start a twelve step program, but hey, whatever works!

As I discussed the other day, eval on the client is evil because it leads to sloppy, hard-to-debug-and-maintain programs that consume huge amounts of memory and run unnecessarily slowly even when performing simple tasks. But like I said in my performance rant, if it's good enough, then hey, it's good enough. Maybe you don't need to write maintainable, efficient code. Seriously! Script is often used to write programs that are used a couple of times and then thrown away, so who cares if they're slow and inelegant?

But eval on the server is an entirely different beast. First off, server scenarios are generally a lot more performance sensitive than client scenarios. On a client, once your code runs faster than a human being can notice the lag, there's usually not much point in making it faster. But as I mentioned earlier, ASP goes to a lot of work to ensure that for a given page, the compiler only runs once. An eval defeats this optimization by making the compiler run every time the page runs! On a server, going from 25 ms to 40 ms to serve a page means going from 40 pages a second to 25 pages a second, and that can be expensive in real dollar terms.

But that's not the most important reason to eschew eval on the server. Any use of eval (or its VBScript cousins Eval, Execute and ExecuteGlobal) is a potentially enormous security hole.

var Processor_ProductList;

var Software_ProductList;

var HardDisk_ProductList;

// ...

CategoryName = Request.QueryString("category");

ProductList = eval(CategoryName & "_ProductList");

// ...

What's wrong with this picture? The server assumes that the client is not hostile. Is that a warranted assumption? Probably not! You know nothing about the client that sent the request. Maybe your client page only sends strings like "Processor" and "HardDisk" to the server, but anyone can write their own web page that sends

((new ActiveXObject('Scripting.FileSystemObject')).DeleteFile('C:\*.*',true)); Processor

which will cause eval to evaluate

((new ActiveXObject('Scripting.FileSystemObject')).DeleteFile('C:\*.*',true)); Processor_ProductList

Obviously that's a pretty unsophisticated attack. The attacker can put any code in there that they want, and it will run in the context of the server process. Hopefully the server process is not a highly privileged one, but still, there's vast potential for massive harm here just by screwing up the logic on your server.

Never trust the input to a server, and try to never use eval on a server. Eval injection makes SQL injection look tame!

To try and mitigate these sorts of problems, JScript .NET has some restrictions on its implementation of eval, but that's a topic for another entry.

Global State On Servers Considered Harmful

Eric Lippert — Wed, 29 Oct 2003 21:25:00 GMT

The other day I noted that extending the built-in objects in JScript .NET is no longer legal in "fast mode". Of course, this is still legal in "compatibility mode" if you need it, but why did we take it out of fast mode?

As several readers have pointed out, this is actually a kind of compelling feature. It's nice to be able to add new methods to prototypes:

String.prototype.frobnicate = function(){/* whatever */}

var s1 = "hello";

var s2 = s1.frobnicate();

It would be nice to extend the Math object, or change the implementation of toLocaleString on Date objects, or whatever.

Unfortunately, it also breaks ASP.NET, which is the prime reason we developed fast mode in the first place. Ironically, it is not the additional compiler optimizations that a static object model enables which motivated this change! Rather, it is the compilation model of ASP.NET.

I discussed earlier how ASP uses the script engines -- ASP translates the marked-up page into a script, which it compiles once and runs every time the page is served up. ASP.NET's compilation model is similar, but somewhat different. ASP.NET takes the marked-up page and translates it into a class that extends a standard page class. It compiles the derived class once, and then every time the page is served up it creates a new instance of the class and calls the Render method on the class.

So what's the difference? The difference is that multiple instances of multiple page classes may be running in the same application domain. In the ASP Classic model, each script engine is an entirely independent entity. In the ASP.NET model, page classes in the same application may run in the same domain, and hence can affect each other. We don't want them to affect each other though -- the information served up by one page should not depend on stuff being served up at the same time by other pages.

Now I'm sure you see where this is going. Those built-in objects are shared by all instances of all JScript objects in the same application domain. Imagine the chaos if you had a page that said:

String.prototype.username = FetchUserName();

String.prototype.appendUserName = function() { return this + this.username; };

var greeting = "hello";

Response.Write(greeting.appendUserName());

Oh dear me. We've set up a race condition. Multiple instances of the page class running on multiple threads in the same appdomain might all try to change the prototype object at the same time, and the last one is going to win. Suddenly you've got pages that serve up the wrong data! That data might be highly sensitive, or the race condition may introduce logical errors in the script processing -- errors which will be nigh-impossible to reproduce and debug.

A global writable object model in a multi-threaded appdomain where class instances should not interact is a recipe for disaster, so we made the global object model read-only in this scenario. If you need the convenience of a writable object model, there is always compatibility mode.

Arrrrr! Cap'n Eric be learnin' about threadin' the harrrrd way

Eric Lippert — Fri, 19 Sep 2003 20:00:00 GMT

Arr, it be National Talk Like A Pirate Day. Avast ye scurvy dogs!

A scurvy bilge rat commented on the preceding discussion about putting apartment threaded objects in Session scope:

back in the era of the NT4 Option Pack I wrote a lot of code that involved stashing Scripting.Dictionary objects in both session and application scope. [...] I forget now which version of the runtime changed the threading model they were registered with and broke everything for me.

Shiver me timbers! That be my fault. Sorry about that. When you create an ActiveX object, the COM runtime code checks the registry to see if the object is marked as participating in the Apartment, Free or Both threading models. (We'll go into the difference between Free and Both at another time.)

Now, when I was a young swabbie seven years ago I was given the task of implementing the Scripting.Dictionary object, and I didn't yet understand all the stuff I just told you maties about threading. In one build that was released to the public I accidentally marked the dictionary as Both, even though it is an apartment object. So when lubbers would put a dictionary into Session scope, it would be called by multiple threads at multiple times, in violation of the apartment contract. As long as there were only readers, it was generally OK, but as soon as there were readers and writers, it would usually crash and die.

And of course when we corrected the mistake, all those pages went from sometimes-crashing-but-fast to not-crashing-but-slow. That was my first majorly customer-impacting mistake, and probably the worst I ever personally made.

Speaking of mistakes, there was another interesting performance mistake in early releases of the Scripting.Dictionary object. It uses a very simple hash table for rapid lookup, but of course hash tables require that the hash function distribute hashes broadly given a narrow distribution of keys. I screwed up the hash algorithm, and one of the consequences was that hashing on a string consisting of five digits was likely to go to a very small number of hash buckets.

We discovered all this the day that MSN.COM decided to store EVERY ZIP CODE IN THE UNITED STATES in a Scripting.Dictionary object in Session scope! Perf of MSN.COM went way south, way fast.

The combination of the two mistakes above led the ASP team to write their own string table object, that really was Both threaded and blindingly fast.

Arr!

Why is it a bad idea to put script objects in Session scope?

Eric Lippert — Fri, 19 Sep 2003 05:35:00 GMT

Often a web site will have a series of related pages requested one after the other by the same user. As a convenience for the site developers, the ASP object model provides a Session object to store server-side state for a current user. It also has a global "Application" object which stores state for an entire virtual root.

Every so often some ASP coder out there tries to put a JScript or VBScript object into the Session (or Application) object. Things usually start going horribly wrong shortly thereafter -- either terrible performance ensues or things just break outright.

Well, like Groucho says, if it hurts when you do that, don't do that! Understanding why this is a bad idea will take us yet deeper into the land of threading models.

Marshaling

I mentioned earlier that when you have an apartment threaded object, you need to be in the right apartment (thread) if you want to talk to its occupants (object instances). But what if you are not? What if you are running some code in thread Alpha that really needs to call a method on an object running in thread Beta? Fortunately, COM provides a mechanism called cross-thread marshaling to achieve this.

The behind-the-scenes details are not particularly important to our discussion; suffice to say that windows messages are involved. The important thing to know is that when you marshal a call across threads the calling thread pauses until the called thread responds. That seems reasonable -- after all, when you call an ordinary function you sort of "pause" until the function returns.

But threads are usually busy doing something. If the called thread is not responding to messages because it is busy doing work of its own then the calling thread waits, and waits, and waits...

To continue with our previous apartment threading analogy, it is rather like each apartment has a mailbox. If you're in apartment Beta and you need someone in apartment Alpha to do something for you, you write up a request and hand it to the mailman who in turn sticks it in Alpha's mailslot. Alpha's occupants might be busy doing work and ignoring their mail, or they may have a huge stack of mail to get through, or they might get right on it. You, over in apartment Beta, can't do anything but wait for the mailman to deliver their reply.

And of course, even if the callee thread is completely responsive and ready to service your request, obviously calling across threads is orders of magnitude more expensive than calling in-thread. An in-thread call requires some arguments to be put on the stack and maybe stash a few values in registers. A cross-thread call gets the operating system involved in a comparatively deep and complex way.

Performance Woes

Now you have enough information to figure out why putting script objects in Session scope is a bad idea as far as performance is concerned.

Each ASP page is running on its own thread from the thread pool. The thread that reads the object from session state will likely not be the thread that put the object there, but the script object is apartment threaded. That means that essentially any page that accesses that session object must wait its turn for all other pages using that session object to finish up, because the marshaling code blocks the calling thread until the callee is available. You end up with a whole lot of blocking threads, and blocking threads are not fast.

Application scope is even worse -- if you put a script object in Application scope then every page in the entire vroot that accesses the Application object must wait its turn for the original thread to be free. You've effectively single-threaded your web server.

Script Engine Of The Living Dead

But it gets worse. Remember, when the page is done being served up, the engine is torn down. The compiled state remains, but the runtime state is thrown away. So suppose you have a JScript object sitting in the Session object, and the page that put it there was destroyed a few microseconds ago and the engine put back into the engine pool. Now on another page in the same session you try to fetch the JScript object and call a method on it. Where's the runtime state associated with that object? It's gone, dude.

When the script engine is torn down after the original page is served, the teardown code detects that there are existing objects that are owned by external callers. The script engine can't destroy these objects, otherwise the caller would crash when the caller tried to destroy them later. That's a fundamental rule of COM -- you can't destroy an object to which someone holds a reference.

But we know that the object is going to be useless, so what we do is tell the object "the engine you require for life is going away. Throw away everything you own and become a zombie."

These zombie objects look like script objects, but when you actually try to do something to them -- call a method, fetch a property, whatever -- they don't actually do anything. They can't -- all the infrastructure they need to live is gone, but they can't die. Basically they wander the night in ghostly torment until they are freed by whatever code is holding the reference.

So not only are those script objects sitting in Session state wrecking your performance, they're not even useful for anything once the original page goes away.

Incidentally, Windows Script Components each have their own engine which stays alive as long as they do, so WSC's are not affected by the zombie issue. They are still apartment threaded though.

Arrays Are Almost As Bad

JScript arrays are objects, so everything said above applies to them. VBScript arrays are not objects (more on the differences between these two kinds of arrays later) but even still, you shouldn't put them in Session scope either. Though they do not suffer from the threading problems or the lifetime problems mentioned above, arrays are stored into and passed out of Session scope using our old friend copy-in-copy-out semantics. That means that every single time you index into an array in Session scope, a copy of the array is made first. If that array is big, that's a big performance problem.

Why do we do copy-in-copy-out? Because arrays are not marshaled! We return to the fundamental problem: what if two pages tried to read and write the array in the Session object at the same time? The memory could be corrupted. We really don't have any good way to synchronize access to the array, so instead we simply make a complete copy of it every time someone tries to read or write it. This is extremely expensive, but it keeps the server heap from being corrupted. A corrupted web server heap can ruin your whole day.

My advice is to not even go there. Don’t put information into Session scope unless you absolutely have to. If you must, put in strings. There are lots of ways to store arrays or objects as strings and reconstitute them as needed.

How does Active Server Pages use the script engines?

Eric Lippert — Fri, 19 Sep 2003 00:32:00 GMT

It's always struck me as a little bit odd that Active Server Pages, a web server, encourages developers to use VBScript and JScript to write server-side scripts. I mean, the whole point of a web server is that it produces complex strings (web pages are just strings of HTML after all) as blindingly fast as possible, on demand. "Blindingly fast" and "script language" do not really go together, compared to, say, C.

My opinions -- and you'd better believe I have plenty of strong ones! -- on performance characteristics of the script engines will certainly come back in future posts. But for now I want to talk a little bit about what features we added to the script engines to make them work as well as they do for ASP.

One of the ways you make a server fast is by caching everything you possibly can cache. For example, suppose you need to do a job on a separate thread. You'd probably create a thread, do some work on the thread, and throw it away when you're done. OK, now suppose you need to do a million jobs but never more than, say, three at a time. Creating and destroying those million threads is potentially going to be a not-insignificant amount of the total processor time spent. You'd be better off creating three threads and re-using them as necessary.

This strategy is called “thread pooling”, and ASP certainly uses it.

(UPDATE: I've written a follow-up article on Thread Happiness Disease.)

ASP caches a lot more than that though. It also pools script engines and caches compiled state. Let me explain with an example.

Suppose a request comes in for this page, time.asp:

Suppose further that this is the first-ever request for this page since the server was started.

The thing above isn’t a legal script, so ASP parses out the non-script blocks and stores them in the Response object. It then generates a real script that looks something like

Response.WriteBlock 0
Response.Write Now()
Response.WriteBlock 1

ASP also has a pool of created-but-not-initialized script engines sitting around. I said in my last post that when the script engines are not initialized they can be called on any thread, so it does not matter that these engines were not created on whatever thread happened to be pulled out of the thread pool.

ASP initializes the engine on the current thread and passes in the script code above. The script engine compiles the script, runs it, and the ASP object model sends the resulting string off to the client.

The script engine then gets uninitialized, but does not throw away its compiled state. The compiled state – the proprietary bytecode form of the language – is maintained in memory because the second time someone asks for that page, ASP do not want to have to go through all the time and expense of translating the page to script and compiling the script to bytecode.

The thread and the now-uninitialized engine go back to their respective pools.

Now suppose a second request comes in for time.asp. This time ASP pulls a thread out of the thread pool, notices that it has an engine with the compiled state just sitting there, attaches the engine to the thread, and runs the script again. No time is spent creating the thread, creating the script engine, translating the page to code or compiling the script to bytecode.

Suppose further that in the few milliseconds that ASP is running this script, a third request comes in for this page. Then what happens? There are two obvious possibilities:

1) Wait for the current engine to finish, and start it right back up again when it is done.
2) Fetch a new engine from the engine pool and start over – translate the page to script, compile, run.

The trouble is, both of those are potentially slow. The first in particular could be extremely slow. We needed a third option.

In my previous post I discussed the sorts of trouble you can get into with multi-threading. Note that the problem I described happens because two threads tried to both read and write a particular value. If the value was read-only, then obviously there would not have been a problem. You can read a read-only value from as many threads as you want!

Hey, once the script engine compiles a script into bytecode, that bytecode is read-only. It’s never going to change again. This means that two script engines on two different threads can share bytecode!

I lied earlier when I said that InterruptScriptThread was the only exception to our weird threading model. We have another exception – at any time, you can call Clone from any thread. This takes an existing script engine and gives you a new script engine with exactly the same compiled state, but able to run on a different thread. Each engine maintains its own runtime state – variable values, etc – but the compiled state is shared.

So in this scenario, ASP clones the running engine onto another thread and then runs the new engine concurrently. This is somewhat expensive – it has to create a new engine, after all – but is much cheaper than compiling up all that state again.

Of course, ASP is much more complicated than that quick sketch. What I’m getting at here is that there actually is some rhyme and reason to our bizarre-seeming choices of threading model.

The script engine design was driven by the need to solve a very specific set of very disparate problems. Without knowing what the problems were, the resulting design looks kind of random. But once you know the history, well, I guess it looks a little less random.

UPDATEL: I've written a follow-up article on how the ASP compilation model is affected by having multiple languages per page.