Skills | Performance Tip 7: Encapsulate code in a COM object
If you have a lot of VBScript or JScript, you can often move your code to a compiled COM object, which can improve performance. The compiled code usually runs faster than the interpreted code. Compiled COM objects can access other COM objects through "early bound", which is a more efficient way to invoke COM objects than "late binding" used by the script. There are some advantages to encapsulating code in COM objects (in addition to performance):
COM objects are useful for separating presentation logic from business logic.
COM objects can ensure that code is reused.
Many developers find that code written in VB, C + +, or Visual J + + is easier to debug than ASP.
COM objects also have drawbacks, including initial development time and the need for different programming techniques. Note that encapsulating a small number of ASPs can cause performance degradation without performance improvements. This situation typically occurs when a small amount of ASP code is encapsulated into a COM object. In this case, the overhead of creating and invoking COM objects exceeds the benefits of compiled code. You should experiment repeatedly to determine what ASP scripts and COM object code combinations produce the best performance. Note that there is a significant improvement in scripting and ADO performance in Windows 2000/iis 5.0 compared to Microsoft Windows Nt®4.0/iis 4.0. Therefore, with the introduction of IIS 5.0, the compilation code has a lower performance advantage than the ASP code. If you are deploying COM components, it is particularly important to test them at a load. In fact, all of the ASP applications should be tested for load.
Tip 8: Get the resources later and release the resources earlier.
Here is a small tip for your reference. In general, it is best to obtain resources later and release resources earlier. This applies to COM objects as well as file handles and other resources. This optimization method is mainly used for ADO connection and recordset. When you are finished using a recordset, say, after displaying a table and its data, you should release it immediately, rather than wait until the page ends. Setting the VBScript variable to nothing is the best practice. Do not let the Recordset go beyond the scope. Also, to release any associated Command or Connection objects (do not forget to call Close () until you set the recordset or connection to = Nothing.) This shortens the time that the database must prepare resources for you and frees the database to connect to the connection pool as soon as possible.
Tip 9: Process performance in exchange for reliability
Both ASP and mts/com+ have configuration options that allow you to balance reliability and performance. When you build and deploy your application, you should know how to balance the performance of both. The ASP option can configure ASP applications to run in one of three ways. In IIS 5.0, the term "isolation level" is introduced to illustrate these options. These three isolation levels are low-level, intermediate, and advanced, respectively:
Low-level isolation: This is supported in all versions of IIS and is the fastest. It runs Asp,inetinfo.exe in Inetinfo.exe is the primary IIS process. If the ASP application crashes, IIS crashes as well. (To restart Iis,web under IIS 4.0 The site administrator should use tools such as Inetmon to monitor the site and, if the server fails, enable the batch file to restart the server.) IIS 5.0 introduces a reliable reboot, which causes the failed server to be restarted automatically. ）
Intermediate Isolation: IIS 5.0 introduces this new level, which is called an out-of-process level because the ASP runs outside of the IIS process. In intermediate isolation, all ASP applications that are configured to run as intermediate isolation share a process space. This reduces the number of processes that are required to run multiple out-of-process ASP applications on a single server. Intermediate isolation is the default isolation level in IIS 5.0.
Advanced Isolation: This level is supported in IIS 4.0 and IIS 5.0, and advanced isolation is also out-of-process. If the ASP crashes, the WEB server does not crash. The ASP application will automatically restart the next time an ASP request is requested. In advanced isolation, each ASP application that is configured to run as an advanced quarantine runs in its own process space. Doing so protects the ASP applications from interfering with each other. The disadvantage is that it requires a separate process for each ASP application. When you have to run many applications on a single server, the overhead is greatly increased.
Which option is the best? In IIS 4.0, the process Sinotrans line will significantly degrade performance. In IIS 5.0, many improvements have been made to minimize the overhead of running an ASP application out-of-process. In fact, in most tests, an ASP out-of-process application in IIS 5.0 runs faster than an in-process application in IIS 4.0. In any case, in-process (low isolation level) performance is best on two platforms. However, if the access rate is relatively low or the maximum throughput is low, the advantages of the low isolation level are not obvious. Therefore, when you need hundreds of or thousands of pages per second for each WEB server, you will feel the need to set a low isolation level. As always, you should test a variety of configurations to determine which compromise you want to take.
Note When you run an ASP out-of-process application (intermediate or advanced isolation), they run in MTS in NT4 and in COM + in Windows 2000. That is, they run in Mtx.exe in NT4, and in Windows 2000 they run in DllHost.exe. You can see these processes running in Task Manager. You can also see how IIS configures an MTS package or a COM + application run for an out-of-process ASP application. You can also see how IIS configures an MTS package or COM + application for an out-of-process ASP application.
COM Options
COM components also have three configuration options, although not exactly the same as the ASP option. A COM component can be "Not configured", configured as a library application, or configured as a server application. "Not configured" means that the component does not register COM +. Components will run in the process space of the calling program, that is to say, they are in-process. Library applications are also in-process, but use COM + 's services, including security, transaction, and context support. Server applications are configured to run in their own process space.
You can see that the components that are not configured have a slight advantage over the library application. Library applications have a greater performance advantage than server applications. This is because the library application runs in the same process as the ASP, and the server applications run within their own processes. Calls between processes are more expensive than in-process calls. Also, when you pass data, such as a recordset, between processes, you must copy all of the data between the two processes.
Trap! When using a COM server application, if you pass an object between ASP and COM, make sure that the object performs a collection by value or MBV. The objects that perform the MBV copy themselves from one process to another. This is better than one of the following methods, where the object is still in the creator's process, and another process repeatedly calls the create process to use the object. Disconnected ADO recordsets are "pooled by value", and the connected Recordset is not. Scripting.Dictionary do not perform MBV and are not passed between processes.
Finally, VB Programmer please note: MBV is not passed through the parameters ByVal obtained. The MBV is performed by the original component author. What to do?
If we suggest a reasonable configuration that takes account of both performance and reliability, they should be configured as follows:
In IIS 4.0, using the ASP low isolation level, MTS server packages are used.
On IIS 5.0, use the middle isolation level of ASP and use the COM + library application.
These are very general principles, and host services companies typically run ASP at the middle or high isolation level, while a single purpose WEB server can run at a low isolation level. Weigh the pros and cons and decide which configuration is more suitable for your needs.
Tip 10: Use an explicit option
Option Explicit should be used in the. asp file. This directive is placed at the top of the. asp file, which forces the developer to declare all the variables to be used. Many programmers think this approach is helpful for debugging an application because it avoids the possibility of keying variable names and myxmlstring= new variables (for example, to write a mistake as a myxlmstring= ...).
A more important point may be that the declared variable is faster than the undeclared variable. Thus, each time the script uses an undeclared variable at run time, it refers to it by name. On the other hand, declared variables are sequential, either at compile time or at run time. Later, the declared variables are referenced in this order. Because Option Explicit enforces variable declarations, it ensures that all variables are declared, so access is fast.
Tip 11: Use local variables in subroutines and functions
Local variables are those declared within subroutines and functions. Within a function or subroutine, local variable access is faster than global variable access. The use of local variables also makes the code clearer, so you should try to use local variables as much as possible.
Tip 12: Copy frequently used data into a script variable
When you access a COM object in ASP, you should copy the frequently used object data into the script variable. Doing so reduces the COM method invocation because COM method calls are relatively expensive compared to accessing script variables. This technique also reduces costly lookups when accessing collection and Dictionary objects.
In general, if you plan to access object data more than once, you should put the data in a script variable. The main goal of this optimization is the Request variable (Form and QueryString variables). For example, your site can pass a QueryString variable named UserID. Suppose this UserID is referenced 12 times on a specific page. You do not need to invoke Request (? UserID?) 12 times, but at the top of the ASP page to assign UserID to. You do not need to invoke Request (? UserID?) 12 times, instead of assigning UserID to a variable at the top of the ASP page. The variable is then used throughout the page. This eliminates the 11 COM method calls. In fact, the overhead of accessing a COM property or method is not that large.
Tip 13: Avoid the ability to redefine the dimensions of an array
You should try to avoid Redim arrays. In terms of performance, if your computer's physical memory size is limited, it's a good idea to set the initial dimension of the array to its most unfavourable condition-or set the dimension to its best case, and then redefine the dimension as needed. This does not mean allocating a few megabytes of memory if you know that you do not need memory.
The following code shows you the improper 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?
MyArray (5) = yet more stuff?
%>
It's best to start by making the initial size of the array Dim correctly (in this case, 5) much better than the Redim array. You may be wasting some memory (if you don't use all the elements), but the benefit is getting faster.
Tip 14: Use response buffering
You can buffer the entire page you want to output by enabling response buffering.
