Describes the flow for the execution of an ActiveServerPage.
Please note, this is an estimation and may be lacking minor details. It is only meant to capture the jist of the flow and to help squash any common misconceptions.
1) URL ending in an ".asp" is requested 2) InternetInformationServer forwards the request to the associated IsapiExtension which, as you probably guessed, is the ASP IsapiExtension. 3) The extension checks its cache for an available ScriptingEngine. 3a) If the ASP file was not cached at all: 3a.1) It is loaded and all SSI instructions are processed 3a.1) It is then compiled to a form of byte-code by the ScriptingEngine associated with the language that the ASP is written in, then step 3b.1a is executed using this instance. 3b) If the file was cached: 3b.1) The ASP IsapiExtension checks to see if an instance of a ScriptingEngine is available in its pool for the requested ASP. 3b.1a) If one is available: 3b.1a.1) The ScriptingEngine is configured with the current ASP request context (i.e. it's handed the Server, Application, Session, Request, Response objects) 3b.1a.2) The script is executed 3b.1b) If one is not available: 3b.1b.1)The ASP IsapiExtension chooses a likely candidate and waits for it to complete, then goes to step 3b.1a.1
A pool of scripting engines is maintained per AspApplication. Step 3a is avoided at all costs by using a feature of the ScriptingEngine architecture known as "cloning". Essentially, when a scripting engine is "cloned", the internal, compiled byte-code is simply transferred to a new instance of the engine. That engine is then returned and can be configured and executed independently of the source engine. This helps improve performance tremendously.
The pool's settings are just another group of settings for an AspApplication.
See also: ActiveServerPages