Include 813
There are two major differences between processing #include files in ASP and using compiled advanced programming languages, such as C + + processing including files.
First, the ASP does not remove the information that is not involved from the resulting ASP file. This is because the ASP is independent of the scripting engine and does not do much code
Analysis. Generally speaking, if you encounter the basic syntax request for an ASP file, the information is cached (assuming the buffer is open) and sent to the appropriate
scripting engine for further decomposition, tagging, and execution.
In addition to this "dead code" problem, the other difference between an ASP's file and the compiled language is that each ASP file can be viewed as its own
of the program. As long as a page does not contain another, in the sense of the ASP they are not related, although both of the operation of the entire site is
The essential. Therefore, a #include file that is shared by two different pages must be fully contained in all two files. In essence, ASP does not have
The advantages of connectors available in many advanced languages enable connectors to avoid the redundancy of code and data contained in a file.
If you combine the problem of the ASP inclusion file that I have outlined, the conclusion is that it will be destructive to the memory of a large site. Imagine
In this case: A containing file contains all the shared programs that you might want to use. Following this design, the result is that all ASP pages
Must contain this critical document. If the everythingbutthekitchensink.inc is decomposed and the average length of the ASP file is the same,
Then half of the memory allocated by the ASP and used for the cached ASP file is full of unwanted information.
813
Call the NT Task manager/processes to see the memory being used by the site and observe how much memory is made up of Mtx.exe
(If the site is set up as a stand-alone program to run on IIS4), Dllhost.exe (if the site is set up as a stand-alone program running on the IIS5),
or inetinfo.exe (if not independent, see figure below) used by these programs. Want to master how fast memory increases, a good
The test method is to start IIS and call a simple page to see the size of the memory. (To call an ASP file before you look at memory, because in the processing of the first
An ASP file to create some common common files. Now use other ASP files on your site and monitor each ASP that is used
The function of a piece on memory.
For example, I created an ASP file. The first file, runfirst.asp, is a small file that initializes an ASP resource before the memory is observed. Other than that
Two files are exactly the same except for the #include file information they want to use. Copy these files to your Wwwroot directory,
Then run runfirst.asp, helloworld1.asp and helloworld2.asp sequentially, executing helloworld1.asp and helloworld2.asp
After watching the memory, you will find that the latter uses more memory. This is because it uses a large unused program in the #include file,
bigandunreferenced, it has no effect on the results of the page's operation, but it occupies 400K of memory. In Windows Server
The results of the following steps in the W/IIS5 are:
Memory 6,104k after running runfirst.asp
Memory 6,124k after running helloworld1.asp
Memory 6,544k after running helloworld2.asp
There is no obvious meaning in this order, and the result of reversing the load sequence is:
Memory 6,096k after running runfirst.asp
Memory 6,536k after running helloworld2.asp
Memory 6,540k after running helloworld1.asp
Note that the number of memory at the beginning and end is not exactly the same because the memory manager allocates the memory in large chunks according to the most recent request. But relatively speaking,
The final contour always helloworld2.asp occupy a large chunk of the memory share. You can download these short code at the end of this article. Browse the following
Code, but to distinguish between memory:
The runfirst.asp is like this:
<%@ language= "VBSCRIPT"% >
< HTML >
< head >< TITLE >seed Page to load General ASP resources</title >< head >
< BODY >
<%
Response.Write "Seed Page Loaded"
% >
</body >
The helloworld1.asp is like this:
<%@ language= "VBSCRIPT"% >
<!--#include virtual = "/helloworld1.inc"-->
< HTML >
< head >< TITLE >hello World using little memory</title >< head >
< BODY >
<%
SayHello
% >
</body >
The Helloworld1.inc code is:
<%
Sub SayHello
Response.Write "Hello World 1"
End Sub
% >
The helloworld2.asp code is:
<%@ language= "VBSCRIPT"% >
<!--#include virtual = "/helloworld2.inc"-->
< HTML >
< head >< TITLE >hello World using a lot of memory</title >< head >
< BODY >
<%
SayHello
% >
</body >
But the helloworld2.inc are bigger:
<%
Sub SayHello
Response.Write "Hello World 2"
End Sub
Sub bigandunreferenced
' This does a lot of the redundant stuff to increase memory
Dim Textvar
Textvar = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890"
' This is the duplicated 1,000 times
End Sub
% >
The discussion of memory resources in this article is based on buffer opening. If the buffer is not open, the page is loaded in each ASP file set
All parts of the page are executed before releasing the content. Most sites open buffers to some extent, because a large number of clicked sites
Request for such a request to run. Even if the buffer is not opened for some reason, it may still be affected by the #include file problem, showing a memory fluctuation
And the processing speed is slow.
Here are some tips to use for your reference, such as:
Re-construct the include file
Re-constructing the include file may be the easiest thing you can do at the moment. List all included files to find the following signs of the problem:
0 #include does the file contain a variety of functions? The highest memory-efficient inclusion file should be a specific function to reduce the likelihood of a dead code.
For example, a process date and time contains a file, you can divide it into two files, each processing one aspect: A separate ASP only need to deal with a
Type.
0 #include does the file specifically store constants that are common to the entire application? This type of file, depending on its size, can cause problems to occur,
Because they usually need to be included in all other include files, they cause the inclusion of file nesting. Constants can be placed in the
Contains the file. If constants are needed within an ASP file, you can create smaller constant files that are related to their type of use.
0 #include does the file contain invalid functions? Some functions/programs are used by the site in the past, has been over the use of the time is still hanging there.
If you are likely to use them again sometime in the foreseeable future, you should create a document file that is carefully archived, stating that the function/program is
Where they came and when they were moved, instead of leaving them in the active file. Version control system to clean old resources Also
