Programming | Advanced 9.3.5 data cache
The first thing to note is that both the data cache and the recordset cache are used to improve performance, but they are irrelevant. The data cache is a temporary data store that allows data in the cache to be used instead of regenerating new data. This applies only to data that is not frequently changed but is accessed multiple times.
One of the easiest ways to cache data in an ASP is to use application and session-scoped variables. For example, suppose there are some pages that need to select a book type. Normally, you might create a include file that contains the following functions.
<%
Function Booktypes ()
Dim Rsbooktypes
Dim Strquote
Strquote = Chr (34)
Set rsbooktypes = Server.CreateObject ("ADODB. Recordset ")
' Get the book types
Rsbooktypes.open "Usp_booktypes", strconn
Response.Write "<select name=" & Strquote & Lstbooktype & strquote & ">"
While not rsbooktypes.eof
Response.Write & "<OPTION>" & Rsbooktypes ("Type") & "</OPTION>"
Rsbooktypes.movenext
Wend
Response.Write & "</SELECT>"
Rsbooktypes.close
Set rsbooktypes = Nothing
End Function
%>
This is just a call to a stored procedure to get the type of book and create a select list. The disadvantage of the preceding code is that the database must be accessed each time the function is invoked. So, modify this function again.
<%
Function Booktypes ()
Dim Rsbooktypes
Dim Strquote
Dim strlist
' The ' if ' the list is in the cache
Strlist = Application ("Booktypes")
If strlist = "" Then
' Not cached, so builds up list and cache it
Strquote = Chr (34)
Set rsbooktypes = Server.CreateObject ("ADODB. Recordset ")
' Get the book types
Rsbooktypes.open "Usp_booktypes", strconn
Strlist = "<select name=" & Strquote & Lstbooktype & strquote & ">"
While not rsbooktypes.eof
Strlist = strlist & "<OPTION>" & Rsbooktypes ("type") & "</OPTION>"
Rsbooktypes.movenext
Wend
Strlist = strlist & "</SELECT>"
Rsbooktypes.close
Set rsbooktypes = Nothing
' Check the list
Application ("booktypes") = Strlist
End If
Booktypes = Strlist
End Function
%>
This code does not just open the recordset, it checks to see if the value of the application variable BookType is empty. If not empty, the contents of the variable are used. If blank, open the recordset as before. Obviously, once the first person runs this routine, the data is cached, so this is only useful for data that is not always changing.
If you want to cache data on a user basis, you can use a session-scoped variable, but note that the session has a validity period. After expiration, the session-level variable will be canceled with the conversation, and the code may end up running.
Using the Web Application Stress (was) tool, the analysis results of table 9-4 are obtained:
Table 9-4 Analysis results obtained using the WAS tool
Method
Number of page clicks
No cache
190
There is a cache
11000
It is obvious that performance has improved. But do not use the above method to cache all content. After all, this approach applies only to data that has been formatted for display. In addition, consider that if the Web server serves only a specific person, it is hardly a typical Web server usage. By using was, you can simulate multiple users on a single server, which allows you to test your application more realistically.
By simulating a certain number of users, the Web Application Stress tool can test the endurance of a Web page. The tool has a simple graphical interface that is easy to use. You can get more information from http://homer.rte.microsoft.com/, or you can download the tool.
Cache objects
What do I do if I want to cache unformatted data? Can it be used differently in different places? Of course, you can do this with application or session variables. Consider the title of the book. You may want to use this title on multiple pages, perhaps displaying all the headings in a table, or displaying them in a list box for user selection, and so on. You might think that you can cache the recordset itself without caching the HTML text that contains the label.
You can cache objects in application or session variables, but there are two major issues to note:
· Objects stored in the application variable must support free threading, and therefore must be either a free thread object or a two-thread object. This means that components created by VB cannot be cached in the application variable.
· Holding a unit thread object in session state means that the thread that created the object is the only thread that is allowed to access it. As a result, IIS cannot perform thread management well because any page that attempts to access the object must wait for the original thread to serve the page. This will kill any opportunity to extend the application.
For a discussion of threading issues, see Chapter 15th.
By default, ADO is loaded as a unit thread object, primarily because some OLE DB providers are not thread-safe. In the ADO installation directory, there is a registry file that transforms ADO into a two-threading model, making it safe for ADO objects to be stored in application and session objects.
You might think that all the problems are solved by using various types of objects to get a significant speed boost, but that's not necessarily the point. Many people have realized that since connecting to a database is a relatively expensive operation, caching connection objects can save a lot of time when connecting again. Yes, but caching the connection object means that the connection will never shut down, so the connection to the cache pool is less efficient. The implicit idea of a connection cache pool is actually to reduce the resources used on the server, while caching objects in the ASP state obviously does not reduce the use of resources. In fact, they are also increased, because each one of the objects will consume the resources of the server, which will greatly reduce the efficiency of the Web server for a busy site.
So the connection object should not be stored, but for the Recordset object, especially the disconnected recordset? Assuming that ADO has changed from a cell thread to a two-thread, there's no reason to not do so, as long as you know exactly what you're doing. Don't think this will automatically improve the performance of your ASP pages. Each cached recordset occupies the server's resources in terms of memory and ASP management, so do not cache large recordsets.
Another trick is to use the GetRows method of the recordset to convert the recordset to an array. Because
[1] [2] [3] Next page
