ASP Technology and the XML DOM


Alan McBee
Microsoft Corporation

September 20, 1999

Download Xml9909.exe.

Just to clear up a possible point of confusion right away, I am not Charlie Heinemann's ghostwriter, nor is he mine. Charlie has had a wonderful time using XML to help his cousin, Uncle Edd, and Junior, Jenny, the intern from Ottawa, and everyone in the world who needed to keep track of their New Kids on the Block albums. However, Charlie needed to focus on some other projects right now. So I've stepped in.

Here it is: September, 1999. The U.S. football season has started, new television shows are about to debut, and the XML DOM doesn't scale well to multithreaded late-bound Automation controllers, such as Visual Basic® Scripting Edition (VBScript) in ASP.


It's true, at least for now: The performance of a Web application, where the application is written in Active Server Pages (ASP) code, and the script uses the XML Document Object Model (DOM), will begin to suffer under load. Microsoft is currently working on this problem.

I'll talk about an alternate approach to using ASP technology to work with the XML DOM—one that should help your server-side XML processing go much faster.

XML DOM on the Web Server

Before we get started, I have a question. Why would you want to use the XML DOM on the Web server to begin with? After all, one of the great things about XML, as Charlie pointed out in Using XSL to Sort and Filter Your Data, is that your Web browser can reuse the XML it downloads. It doesn't have to hit the server every time the user wants to change the way the data looks in the Web application, as it does for straight HTML.

When XML is cached by the client browser, your Web applications can be very responsive to users. However, this works only as long as every client browser properly supports XML, such as Internet Explorer 5. What do you do if you must support browsers that don't handle XML as well? You could send only HTML, not XML. Nevertheless, you'll want to keep your source data in XML, too, or you wouldn't be reading this article. Obviously, you'll have to take care of transforming the XML into HTML on the server.

In My XML, Your Browser, Charlie told us about a Web-based scheduling application, which used XML and XSL, and which worked very well for him in Internet Explorer 5. His colleague, however, didn't have Internet Explorer 5, so Charlie had to produce HTML files for his colleague's browser. At the same time, he still wanted to send XML and XSL to Internet Explorer 5 browsers.

Charlie turned to ASP technology for a solution. By examining the HTTP header HTTP_USER_AGENT, Charlie was able to tell whether the browser was Internet Explorer 5. He used one procedure to send XML and XSL to Internet Explorer 5. He used a different procedure to do what Internet Explorer 5 does with XML and XSL -- only the procedure did it at the server instead.

The results of the two processes look identical, even though they were delivered to the browsers in very different ways. When Internet Explorer 5 gets an XML stream that uses an XSL style sheet at the client, it uses the XSL to transform the XML into HTML. It takes that HTML and displays it. However, if the ASP script does this transformation at the server, it will be doing exactly the same transformation that Internet Explorer would have done, thus getting the same HTML output. The ASP script can then send that HTML to any browser.

It sounds good. Unfortunately, performing that transformation on the server requires the ASP scripting engine to make late-bound calls (think "interpreted programming language" -- it's close) to the XML DOM component. When your server is taking a thousand hits each minute, it must transform that XML very, very fast. Due to the above-mentioned problem about the XML DOM not scaling well, ASP scripts calling the XML DOM don't perform well under stress.

Enter Visual Basic WebClasses. A WebClass is an optimized, compiled component. Unlike ASP script, it can be early-bound to the XML DOM. This increases its potential speed many times over. Visual Basic makes the essential ASP objects, Server, Request, Response, Session, and Application, available to the WebClass, so porting your ASP code to WebClass code a breeze.

Let's compare them and see. We saw this ASP script originally in the column, "My XML, Your Browser":

client = Request.ServerVariables("HTTP_USER_AGENT")
version = Split(client,";",-1,1)
IF version(1) = " MSIE 5.01" Then%>
      <XML ID="XMLDoc"></XML>
      <XML ID="XSLDoc"></XML>
      <DIV ID="insertHTML"></DIV>
        XMLDoc.async = false
        XSLDoc.async = false
        result = XMLDoc.documentElement.transformNode (XSLDoc.documentElement)
        insertHTML.innerHTML = result
  Set XMLDoc = Server.CreateObject("Microsoft.XMLDOM")
  Set XSLDoc = Server.CreateObject("Microsoft.XMLDOM")
  XMLDoc.async = false
  XSLDoc.async = false

End IF

Here's the equivalent code in a Visual Basic WebClass:

Option Explicit
Option Compare Text
Private Sub WebClass_BeginRequest()
   Dim XMLDoc As MSXML.DOMDocument
   Dim XSLDoc As MSXML.DOMDocument
   Dim client As String
   Dim version() As String

   client = Request.ServerVariables("HTTP_USER_AGENT")
   version = Split(client, ";", -1, 1)
   If version(1) = " MSIE 5.01" Then
      With Response
         .Write "<HTML>" & vbCrLf
         .Write "   <BODY>" & vbCrLf
         .Write "      <XML ID=""XMLDoc""></XML>" & vbCrLf
         .Write "      <XML ID=""XSLDoc""></XML>" & vbCrLf
         .Write "      <DIV ID=""insertHTML""></DIV>" & vbCrLf
         .Write "      <SCRIPT LANGUAGE=VBScript>" & vbCrLf
         .Write "         XMLDoc.async = False" & vbCrLf
         .Write "         XMLDoc.Load (""schedule.xml"")" & vbCrLf
         .Write "         XSLDoc.async = False" & vbCrLf
         .Write "         XSLDoc.Load (""schedule.xsl"")" & vbCrLf
         .Write "         result = XMLDoc.documentElement.transformNode (XSLDoc.documentElement)" & vbCrLf
         .Write "         insertHTML.innerHTML = result" & vbCrLf
         .Write "      </SCRIPT>" & vbCrLf
         .Write "  </BODY>" & vbCrLf
         .Write "</HTML>" & vbCrLf
      End With
      Set XMLDoc = Server.CreateObject("Microsoft.XMLDOM")
      Set XSLDoc = Server.CreateObject("Microsoft.XMLDOM")
      XMLDoc.async = False
      XMLDoc.Load Server.MapPath("schedule.xml")
      XSLDoc.async = False
      XSLDoc.Load Server.MapPath("schedule.xsl")
      Response.Write (XMLDoc.documentElement.transformNode (XSLDoc.documentElement))
   End If
End Sub

As you can see, the samples are almost identical. They would have been even closer if the original ASP script used the Response object instead of having inline HTML in the ASP file. By the way, the trailing vbCrLf after each Response.Write call is unnecessary, but it makes the HTML source on the client easier to read.

I used the Option Explicit statement in the Visual Basic program. Doing that reminds me to strongly type my variables. In this case, I definitely want to be sure that my object variables, XMLDoc and XSLDoc, are declared with a specific type, and not as Object or Variant types, which is the default. By declaring a specific type, Visual Basic will make my XML DOM method calls early-bound calls instead of late-bound. That's why I moved this program from ASP processing to Visual Basic in the first place.

Now what about that performance problem I mentioned earlier?

The performance improvement you get from switching to WebClasses depends on the number of processors in your Web server, the number of XML DOM calls you are making, and whether XML is the performance bottleneck in your ASP pages. Assuming you have a quad processor machine and ASP pages that are doing hundreds of XML DOM calls per page and nothing else, you will see upward of 150 percent improvement in the maximum number of pages per second that the server can produce. This means if you had a peak throughput of 20 pages per second, then you should see this jump to about 50 pages per second. For a more dramatic example, download Xml9909.exe.


Ideally, you avoid doing any XML transformations on your Web server. Instead, you'll send the XML and XSL down to the browser for it to transform. That certainly would ease the burden on your Web servers well beyond what the WebClasses might do.

Also, remember that XML/XSL isn't just a different way to do the same thing as HTML with style sheets. That is just one well-established application. XML can be used for many other solutions. Look at BizTalk for examples of XML being used for e-commerce and application messaging.

Alan McBee is a technical writer on contract to Microsoft's Data Access/XML User Education team. He has been brought to you by the letters C and N, and by the number 12.