Question:

Hi David,

Do you have any idea whatsoever of why ASP output is not buffered and the performance on our IIS 6.0 servers are truly bad? Moreover, the weird part is that this does not happen when you open the "problem pages" locally on the server.

The pages are not buffered when they exceed about 300-400KB (a lot, I know, but ...). And it is actually possible to kill the machine by rapidly refreshing the pages, it will allocate memory until "out of memory" and then shutdown.

From the beginning this were database driven pages so we thought that the database was the culprit but I wrote a couple of ASP test pages that generated 400+ KB data and the problem remained.

The, just out of chance, I renamed the test pages from .asp page to .aspx and guess what? No problems any more.

The pages are not buffered, even though I have set this on the property pages, on the .asp page and even in the MetaBase.

And I think I have tested every registry fix (hack) I know of (UriMaxUriBytes, EnableCopySend, MaxCopyThreshold and more) plus the buffering limits and other similar settings in the MetaBase.

The .aspx test page takes less than one second while the .asp page, with the exact same contents, takes almost 10 seconds over a gigabit LAN connection.

We would rewrite the .asp pages if we could - just to fix this - but that is not possible at the moment.

I have spent almost 10 days and installing, configuring and reinstalling the machine(s) several times after tweaking registry settings and the MetaBase just to make sure nothing is wrong. But still no success.

This is on Windows 2003 Server Standard, SP1 and latest december updates. And I have tested this on a slipstreamed SP1 2003 standard, completely, fresh installation (IIS pre-installed via WINNT.SIF config). Dual Xeon, SCSI RAID machines with 4GB memory.

Initially I thought it was some kind of hardware configuration error - but then should the .aspx pages not work either.

We have talked to Microsoft support in our part of the world but no new ideas or suggestions other than what we have already tried.

IIS 6.0, ASP.DLL, HTTP.SYS, TCP/IP or a combination of all things? I have absolutely no idea and nowhere to go at the moment.

Answer:

I usually like to have answers of at least comparable length and detail to the questions, but in this case, I have to say that all the ideas seems to have been tried already, and so my answer is going to be brief. The only things I can add are:

  1. Response.Buffer = true  at the top of an ASP page should be sufficient to turn on response buffering, unless you are also doing Response.Flush(). This used to trigger a performance issue with HTTP.SYS, but that is fixed in SP1 when HTTP.SYS introduced response buffering of its own. FYI: Your symptoms sound as if you do not have the HTTP.SYS fix in SP1... we should check HTTP.SYS version.
  2. The official route - Open a Support case with Microsoft Support, get them to contact the PSS folks dedicated to IIS, and get the issue escalated to the IIS QFE team (which for IIS is tightly associated with the product team).
  3. The "unofficial" route - Can you give the example ASP script code and necessary server configuration (i.e. SSL, Compression, keep-alive, etc) to reproduce the issue. It would help me tremendously to have a local repro of your situation so that I can find the necessary developers to take a look. This also helps the QFE team out since getting the proper repro is usually the biggest obstacle. Yes, you still have to open a support case. You just allow me to help you grease the wheels a little... :-)

Feel free to attach any comments as necessary. Sorry it has cost you 10 days of time to get to this point, but your investigative thoroughness should bring you faster resolution.

//David