A practical approach to performance optimization for two ASP

Performance | Optimization 1. Discussion topic: ASP Script Size

Is your script page (and other pages) longer than required?
This is something that will degrade the performance of the ASP at the beginning of execution. ASP scripts are useful when it comes to getting information and formatting output, but scripts are also interpreted on a row-by-line basis, so the longer your script is, the longer it takes to execute it.

If your script is huge, what can you do to reduce the length of the script?
Here are a few suggestions:
You can convert them to server-side components, that is, to make a VB Dynamic link library dll or convert it to an precompiled component through an advanced Windows programming language or an appropriate COM interface language? and register them on the server side. About the quick guide can be found in. Compiling a well written ActiveX component can greatly improve performance and protect your software (scripts), especially if you publish your ASP site on a third-party host.
Because scripts are executed on a row-by-line basis, eliminating redundant scripts or creating more efficient scripts can improve performance. If you have hundreds of lines of code in a single ASP file, you can do a good job of dividing users, trading and data services. In fact, if you do this, you might find some redundant code: If you need to output a few tables, you can write a generic function to output a table, just call it multiple times.
When you talk about the size of an ASP script, you have to mention the size of the included file. When you use a containing file, the entire containing file is loaded, and when the containing file is included, it is equivalent to writing that part of the code in the ASP file itself. So if you define a lot of common methods and definitions in a lengthy inclusion file, realize that when you include the file, whether you want to use every method or definition inside it, it's all loaded. ASP caches all of the unwind code, which reduces lookup efficiency in this case, the inclusion file must be split into smaller, modular files. Also understand that the inclusion file is considered a separate page request by the server, and using too many include files can affect download times.

<!--#includefile = "header.asp"-->
<!--#includefile = "footer.asp"-->
<scriptlanguage= "VBScript" runat= "Server" >

Submain ()
Writeheader
Writebody
Writefooter
Endsub

Subwritebody ()
...
Endsub

Main ' calling procedure Main
</SCRIPT>

If your script is lengthy, use response.isclientconnected. This means that the client is no longer connected to the service
Device, your server CPU can avoid the loop waiting.

<%
' Check if the client is still connected
Ifnotresponse.isclientconnectedthen
' Still connected, ' the handler
Else
' Disconnect
EndIf
%>



Use fast Oledbprovider technology to connect to your database instead of using a DSN connection. You no longer have to plead with your ISP (or database administrator/NMS) to create a System DSN for you, and you don't need to change the configuration when you remove the Web file.
OLE DB is between the ODBC layer and the application. In your ASP page, ADO is a "application" above odedb. Your ADO calls are first sent to OLE DB, which is then sent to the ODBC layer. However, you can connect directly to the OLE DB layer, and if you do, you can see server-side performance improvements.

However, how do I connect directly to OLE DB?
If you use SQLServer7, connect to the database using the following connection code:

strconnstring= "dsn= ';D river={sqlserver};" &_
"UID=MYUID; Pwd=mypwd; " &_
"DATABASE=MYDB; Server=myserver; "

The most important parameter is the driver= part. If you are going to bypass ODBC and use SQL Server by using OLE DB connection (this is faster
Connection), use the following syntax:

Strconnstring= "Provider=SQLOLEDB.1; Password=mypassword; " &_
"Persistsecurityinfo=true; Userid=myuid; " &_
"Initialcatalog=mydbname;" &_
"Datasource=myserver; Connecttimeout=15 "

Is there something wrong here?
Now you may find it a little strange: what are the main points of our new approach to linking? Why not use the standard DSN-LESS/SYSTEMDSN approach? Well, according to Wrox's test results in his book, Ado2.0programmer ' Sreference, if you use OLE DB connectivity and DSN or Dsn-less connection method comparisons, you'll find the following improvements:

Performance comparison:
Sqlaccess
Oledbdsnoledbdsn
Connection time: 1882 connection time: 6299
Query 1,000 records time: 29005400 query 1,000 record time: 100950

Note: This result is available on pages No. 232 and 233 of the book "Ado2.0programmer ' Sreference" in Wrox. The unit of time is milliseconds, and the query 1,000 record time is computed from a server-side cursor (the difference between the performance of OLE DB and the DSN recordset is small when using a client cursor).