Program | performance | Optimizing active Server pages enables dynamic pages to be executed quickly, but adding some skill to the connection to the database in your code allows the program to execute faster. This is an article on how to refine the script and ASP features to achieve maximum speed. Any delay between the user clicking the button and the result on the screen will leave the user at a loss, and for a commercial site, this means potential user losses.
Dimensions of ASP scripts
We may not be able to control the bandwidth of the user, but by optimizing the ASP site, we can actually achieve the best performance for the application. Many potential performance gains can be adjusted through the system rather than changing the code.
Factors
First, what factors may affect the performance of an ASP program? Unfortunately, is there a lot of it? Here are just a few:
Limited bandwidth
Speed of server-side processors and other hardware
Other processes running on the server (for example, one of those OpenGL screen saver programs)
Database connection mode, connection pooling, or a separate database (such as Oracle, SQL Server, Access)
Language of Use
Stored Procedures and SQL
Using an precompiled component, not VB or Javsscript ASP
Good programming habits, such as dealing with errors
Some of these features are common to an experienced developer with good knowledge of IIS, but others can be very complex. In this article, let's look at how we can save milliseconds of time rather than trying to be exhaustive.
Does your ASP script look too long for the functionality you implement? This will affect the performance of the program from the beginning. ASP scripts are useful for gathering information and formatting output, but scripts are interpreted as rows, so the longer the code, the longer the execution time.
If you have a very long ASP script, how can you reduce the length? Here are some suggestions.
You can convert them to server-side components, in other words, create a visual Basic DLL file, or use any modern Windows programming language and COM-compliant language to establish an precompiled component and register on the server. For a tutorial on this feature, see http://www.webdevelopersjournal.com/articles/activex_for_asp.html. A well-written ActiveX component can not only greatly increase the speed, but also greatly improve the protection of your software, especially when you are developing an ASP program for a 3rd party.
Because the script is executed on a line of lines, eliminating redundant scripts or creating efficient scripts can improve program performance. If you have hundreds of ASP scripts on a single page, you might be able to split the program into user, business, and Data Services sections. In fact, if you do, you'll find some extra code. For example, if you need to display a few tables, you can write a generic table display function so that you can call it where you need it.
Another problem with dimensions is the length of the containing file. When a #include file is executed, the entire file is called in as if it were contained in the file. So, if you have a redundant inclusion file that contains a number of global methods and variable definitions, be aware that they will be transferred to each file containing them, regardless of whether they are available or not. The ASP caches all the extension code, resulting in inefficient searches. In this case, the include file must be smaller. Although the containing file is processed by the server as a separate request, excessive use of #include can lead to an excessive download time.
<!--#include file= "header.asp"-->
<!--#include file= "footer.asp"-->
< SCRIPT language= "VBScript" runat= "Server" >
Sub Main ()
Writeheader
Writebody
Writefooter
End Sub
Sub Writebody ()
...
End Sub
Main ' Call Sub Main '
</script >
If the script is very long, note that you want to use the response.isclientconnected command, which will prevent the CPU from wasting running cycles when the client is no longer connected.
<%
' Check to ' if the ' client is connected
If not response.isclientconnected Then
' Still connected so proceed
Else
' Disconnected
End If
% >
Disperse ASP code and HTML language commands
Does anybody do that? When describing a table, switch between ASP and HTML, for example:
< HTML >
< BODY >
<%
Set myconn = Server.CreateObject ("ADODB. Connection ")
Mdbfilepath = Server.MapPath ("Sample.mdb")
MyConn.Open "Driver={microsoft Access Driver (*.mdb)}; Dbq= "& Mdbfilepath &";
Sql_query = "SELECT * FROM Friends"
Set RS = Myconn.execute (sql_query)
While not RS. Eof
% >
< LI ><%=rs ("Name"): < A href= "<%=rs (" Link ")% >" >Homepage</a >
<%
Rs. MoveNext
Wend
% >
</body >
Another example is using the IF command:
<%
If not session ("dbopen") Then
% >
< H1 >database not connected
<%
Else
% >
< H1 >database open
<%
End If
% >
In the above 2 examples, script performance improves performance by keeping ASP blocks on the server side and using Response.Write to generate HTML code, as follows:
<%
If not session ("dbopen") Then
Response.Write "< H1 >database not connected
Else
Response.Write "< H1 >database open
End If
% >
For large and long scripts, you can see significant performance improvements through the above methods.
Session state
Undoubtedly, maintaining State in the ASP through session is a very important feature. However, this will affect the performance of the program. Obviously, the scalability of the server becomes a problem because the session can only be limited to a single server, and a session consumes resources for each user.
If you do not use a session variable, and you may not actually need it, because you can use a hidden form field, store a number in a database, and use a query string to complete the session's function, you should mask the session state, as follows:
@EnableSessionState = False
This way, the ASP will no longer check session information.
If you do rely on session state, avoid storing large amounts of data in the Session object. If you set up the HTTP Cookies for the client, the session in IIS is in effect, and the memory space allocated for each session will remain until the session is aborted or expired. For this reason, when there are many concurrent users accessing the site, the resources will soon be depleted.
