Performance and postprocessing

Storing all those handy procedure wrappers in server-side includes provides great reusability. But I'm sure most of you are questioning the logic of packing so much functionality (and size) into these includes. The obvious performance hit must be heavy indeed. Well let me ease your one million page-views/day concerns. My testing, with a loaded Pentium II 300 MHz server with 128MB memory (running Microsoft Exchange and SQL Server™, plus numerous supporting services), shows how truly responsive these ASP files can be. My test pages contained light graphics, with less than 20KB total per page. Figure A (below) shows my stress test results.
      Assuming a full load for 16 hours a day, 20 hits per second means 1,152,000 hits daily. Each of the scenarios in Figure A easily exceeds these capabilities.
      Conservatively speaking, half a million ASP pages with moderately heavy graphics and data can easily be pumped through such a server per day.
      Now let's talk about postprocessing. A Visual Basic® file is not an ASP. It cannot be turned into an ASP simply by renaming it from .mod or .cls to .asp. A number of things make ASP files unusable. Open up any Visual Basic file in Notepad and you'll see lines such as:


 VERSION 1.0 CLASS
 BEGIN
 MultiUse = -1 'True 
 END
 Attribute VB_Name = "A01"
 Attribute VB_Creatable = False
 Attribute VB_Exposed = False 
All of these will choke the ASP engine. VBtoASP.exe, part of this article's downloadable code, removes these offending lines and prepares the Visual Basic file for use as an ASP.
      To allow for custom postprocessing, I created two comment types that VBtoASP.exe deals with differently. A 'vb comment says "remove the entire line." Prefacing a comment with 'asp strips just the 'asp prefix from the line and lets the rest of the line pass through untouched.
      These comments are used to shield Visual Basic from ASP code lines such as

 <% ... %>
and

 <!--#include virtual="/ASPinVBIDE/Admin.inc" -->
all of which are found in ASP but would cause compile errors in Visual Basic. It's true that Option Explicit is not a foreign statement in ASP. However, more than one Option Explicit will cause an ASP compile error, and each include and ASV file will have its own. To include the Option Explicit statement in your ASP code, place one instance in one include that will remain in your code after postprocessing.
      VBtoASP.exe contains two additional features: it renames ASVs and INVs to .asp and .inc, and it can cut comments from ASP files. Comments in your Visual Basic code are necessary for readability and maintenance, yet because the ASP files are not edited directly, comments can be removed to speed parsing.

Figure A   Stress Test Results

Includes Processing SQL Pages/second
10KB Light No 80–100
20KB Light No 70–80
60KB Light No 50–60
No Light Light 100+
No Light Medium 70–90
No Light Heavy 65–75
No Medium No 75–85
No Heavy No 65–75
10KB Light Light 65–75
20KB Medium Medium 45–55
60KB Heavy Heavy 25–35