Program | How performance enhances ASP program performance (2)
2000-08-11 · Compiling: Gan Ganping · Yesky
Tip 6: Use session objects wisely
Sessions have several drawbacks when they are used on a busy site. Busy means: Hundreds of pages are requested per second on the site, or thousands of users are being accessed at the same time. This technique is important for sites that require horizontal scaling: They use multiple servers to complete data loading or handle large amounts of fault tolerance. For small sites, such as Intranet intranet,session, is well worth advocating.
Again, the ASP automatically creates a session for each user who clicks on the Web server for the first time, with approximately 10KB of memory each, with a lifetime of 20 minutes by default.
The biggest problem with session is not performance, but extensibility, the session cannot span multiple Web servers, and once the session is created on a server, its data resides there. This means that if you use session on the Web, you will need to design a policy for each user who accesses the sessions server directly. This is to "glue" the user on the Web server, the term "sticky sessions" comes from this. If the Web server encounters a barrier, the "stuck" user loses their session status because the sessions are not kept on disk.
Strategies for performing sticky sessions include hardware and software solutions, such as the network Load balancing in Windows2000 Advanced servers, and Cisco's local Director, but in return for these sacrifices some extensibility.
Application objects also cannot span servers. If you need to share and update application data in a Web farm, you need to use a background database. However, read-only application data is still useful in the Web farm.
Many sites that are demanding for a task have at least 2 Web servers set up, so when designing a strict task application, you need to perform "sticky sessions" or simply avoid using the session. You can also take other management techniques that save the user's state to a stand-alone Web server.
If you do not use session, be sure to turn them off, which can be done through Internet Services Manager. If you decide to use session, there are several ways to minimize their impact.
You can move content that does not require a session (such as Help screen, visitor area, and so on) to a stand-alone ASP application that closes the session. On the underlying page, you can give the ASP an indication that it does not need to use session. Add the following code directly to the head of the ASP page:
<% @EnableSessionState =false%>
A good explanation for using this indicator is that the session in the frame structure creates an interesting problem. ASP ensures that only one request from the session is executed at a time, which ensures that if the browser requests multiple pages for a single user, only one ASP request can accept the session at that time, thus avoiding multithreading problems when accessing the Session object. Unfortunately, all the pages in the frame structure will appear in sequential order, one by one, not at the same time, so the user has to wait a long time to see the entire frame. The rule is: if a certain frame page does not use session, be sure to tell the ASP to directly use @enablesessionstate=false.
In addition to using the session object, there are many other options for managing conversation state. For a small number of States (less than 4KB), we usually recommend using cookies, query string variables, and form hidden fields. For large amounts of data like a shopping cart, the backend database is the most appropriate choice.
Tip 7: Load code into a COM object
To write a lot of VBScript or JScript, you can write your code as a COM object and compile it for performance. The compiled code is much faster than the explanatory code, and the compiled Component object can access other COM objects through "early binding", which is more effective than invoking the component in the script.
There are many advantages to doing this:
COM objects benefit from independent expression rules in business rules
COM objects make code reuse possible
Many developers find that using vb,c++ or Visual J + + to write programs is easier to debug than ASP
COM objects also have drawbacks, including initial development time and the need for different programming techniques. Note that a small number of ASP code into COM object components will not benefit, but can lead to loss of performance, thereby losing the advantage of compiling code. How to combine ASP scripts with COM objects to achieve optimal performance is a test issue. We note that Microsoft has massively improved the performance of scripts and ADO on Windows 2000/iis 5.0, thereby reducing the performance advantage of compiling code as the IIS5.0 version is introduced.
Tip 8: Use option Explicit
To use the Option Explicit definition in an ASP file and place it in the head of an ASP file, forcing the developer to declare all variables before use. Many programmers think this is useful when debugging an application because it avoids the possibility of generating error type variables and accidentally creating new variables.
Perhaps more importantly, the declared variable is much faster than the non declaring variable.
Tip 9: Copy frequently used data into script variables
When accessing COM objects in ASP, you should copy frequently used object data into script variables, thus reducing method calls to COM objects. These calls are more time-consuming and laborious than accessing script variables. Using this technique also reduces expensive lookup operations when accessing collection and Dictionary objects.
In general, if you want to access object data more than once, you should put the data into a script variable, which is mainly the request variable (form and query string variable). For example, a site is passing a query string variable called UserID, assuming that it will be referenced 12 times on a particular page, so you do not need to invoke request ("UserID") 12 times, as long as you assign UserID to a variable in the header of the ASP page, and then use it in the page, This saves the invocation of the COM method 11 times.
In practice, accessing COM properties or methods is expensive, and the following example shows the common code:
Foo.bar.blah.baz = Foo.bar.blah.qaz (1)
If Foo.bar.blah.zaq = Foo.bar.blah.abc Then ' ...
After the above code executes, the following events occur:
1. variable foo is treated as a global object
2, the variable bar is considered as a member of Foo
3, variable blah is regarded as a member of the Foo.bar
4, variable Qaz is regarded as a member of the Foo.bar.blah
5, call Foo.bar.blah.quaz (1)
6, then perform steps 1 through 3 decomposition Baz
7, decomposition Baz as a member of the Foo.bar.blah
8, then perform steps 1 through 3 decomposition Zaq
9, then perform steps 1 to 31 decomposition ABC
As shown above, this is very inefficient and very slow. The quicker way is to write code in VBScript as follows:
Set myobj = Foo.bar.blah ' Do the resolution of blah ONCE
Myobj.baz = Myobj.qaz (1)
If Myobj.zaq = Myobj.abc Then ' ...
If you use VBScript 5.0 or later, you can write with the WITH statement:
With Foo.bar.blah
. Baz =. Qaz (1)
If. Zaq =. ABC Then ' ...
...
End With
Note: This technique can also be applied in VB programming.
Tip 10: Avoid defining arrays again
Try not to define the array again. Considering the performance problem, if the machine has insufficient physical memory, it is best to set the initial size of the array in the worst-case scenario or best case, and redefine it as needed.
The following code shows the use of dim and ReDim:
<%
Dim MyArray ()
Redim MyArray (2)
MyArray (0) = "Hello"
MyArray (1) = "Good-bye"
MyArray (2) = "Farewell"
...
' Some other code where the needing more spaces happens, then ...
Redim Preserve myarray (5)
MyArray (3) = "More Stuff"
MyArray (4) = "Even more stuff"
MyArray (5) = "yet more Stuff"
% >
It is very nice to simply define the initial size of the array to fit the size, rather than ReDim the array. This may be a waste of some memory (if space is not fully used), but the speed is won.
