ASP Skill Collection (Official Authority edition)-2

Skills Tip 3: Caching Data and HTML on a WEB server disk
Sometimes, too much data is not cached in memory. "Excess" is a qualitative judgment, depending on the amount of memory that is intended to be consumed, as well as the number of cached items and how often these items are retrieved. In summary, if you have too much data to cache in memory, consider caching the data on the WEB server's hard disk in the form of text or XML files. You can combine cached data on disk with cached data in memory to establish an optimal caching strategy for your site.
Note that when you measure the performance of a single ASP page, retrieving data on disk is not necessarily faster than retrieving data from the database. However, caching eases the load on the database and the network. In a high load situation, this will significantly increase the overall volume of traffic. Caching is very effective when querying the results of cached queries at high cost, such as multiple-table unions or complex stored procedures, or caching large result sets. According to the Convention, test the competition scheme.
ASP and COM provide several tools for building disk caching scenarios. The Save () and Open () functions of the ADO Recordset, which save and load the recordset on the disk. You can use these methods to override the example code in the above application data caching techniques, replacing the code that writes data to the Application object with the Save () file.
There are other components that work with files:
Scripting.FileSystemObject enables you to create, read, and write files.
MSXML is a Microsoft (R) XML parser provided with Internet Explorer that supports saving and loading XML documents.
The LookupTable object (an example used on MSN) is a good choice to load a simple list from disk.
Finally, consider caching the representation of the data on disk, rather than the data itself. Prefabricated HTML can be stored on disk as. htm or. asp files, and hyperlinks can point directly to these files. You can automate the HTML generation process by using business tools such as Xbuilder or the Internet Publishing feature of Microsoft (R) SQL Server. In addition, you can #include an HTML fragment to an. asp file. You can also use FileSystemObject to read HTML files from disk or to use XML for early tuning (English).
　　
　　 Tip 4: Avoid caching inflexible components in application or Session objects
While caching data in application or session objects is a good idea, caching COM objects can be a serious flaw. Embedding common COM objects into application or session objects is usually appealing. Unfortunately, many COM objects, including COM objects written in Visual Basic 6.0 or earlier, can cause serious bottlenecks when stored in application or session objects.
In particular, any inflexible component that caches in session or application objects can cause performance bottlenecks. Flexible components are components marked as Threadingmodel=both (it aggregates free thread aggregator (FTM)) or components marked as threadingmodel=neutral (the new "neutral" model in Windows (R) 2000 and COM +. The following components are non flexible:
Free threaded components (unless they gather FTM).
The unit thread component.
Single threaded component.
Configured components (Microsoft Transaction Server (MTS)/com+ libraries and server packages/applications) are not flexible components unless they are "neutral" threads. Unit thread components and other inflexible components are best suited to work with page scopes (that is, they are created and destroyed on a single ASP page).
In IIS 4.0, components marked as Threadingmodel=both are considered flexible. In IIS 5.0, this is not enough. Components must not only be marked as Both, but must also be clustered FTM. The flexibility article explains how to make the C + + components written with the Activity Template Library aggregate FTM. Note that if the component caches interface pointers, the pointers themselves must be flexible or must be stored in the COM Global Interface Table (GIT). If you cannot recompile the Both thread component so that it aggregates FTM, you can mark the component as threadingmodel=neutral. In addition, if you do not want IIS to perform a flexible check (so that you want the inflexible component to be stored in the application or Session scope), you can set AspTrackThreadingModel to True in metabase. Does not advocate change AspTrackThreadingModel.
If you try to store an inflexible component created with Server.CreateObject in a Application object, IIS 5.0 generates an error. This problem can be resolved by using the <object runat=server scope=application ...> in Global.asa, but this is not advocated, as this will result in aggregation and serialization, as described below.
If caching is not a flexible component, what error will occur? The inflexible component cached in the Session object "locks" the conversation to an ASP worker thread. The ASP maintains a worker thread pool, which serves the request. Typically, the new request is handled by the first available worker thread. If the session is locked to a thread, the request will have to wait for the thread it is associated to become available. For example: You go into a supermarket, pick up some food, and then pay at number 3rd. Since then, every time you buy food in this supermarket, you have to always pay at number 3rd, even if there are fewer or no people at the other checkout desk.
Storing the inflexible components in the Applicaton scope can even have a more severe impact on performance. ASPs will have to create dedicated threads to run flexible, applicaton-scoped components. This will result in two kinds of consequences: all calls have to be pooled to the thread, and all calls are serialized. Pooling means that parameters have to be stored in a shared area of memory, expensive context switches are performed on the dedicated thread, the method of the component is executed, the result is pooled to the shared area, and another expensive context switch allows control to return to the original thread. Serialization means that all methods must run one by one (only one method can be run at the same time). Two different ASP worker threads cannot execute methods on shared components at the same time. This will kill the parallel mechanism, especially on multiprocessor computers. Worse, all of the inflexible, application-scoped components will share a thread ("Host STA"), so the impact of serialization is even worse.
Do you feel confused? Here we propose a few general rules. If you are writing objects with Visual Basic (6.0) or earlier, do not cache them in a application or Session object. If you do not know the threading model of an object, do not cache it. Instead of caching the inflexible objects, you should create and release them on each page. The object will run directly on the ASP worker thread, so that no collection or serialization will occur. If the COM objects are running in the IIS box, and if they do not take a long time to initialize and cancel, the performance will be sufficient. Note that you do not use a Single-threaded object with this method. Be careful: VB can create a single-threaded object! If you have to use single-threaded objects (such as Microsoft Excel spreadsheets) in this way, do not expect high throughput.
Caching an ADO recordset is safe when ADO is marked as a free thread. To mark ADO as a free thread, use the Makfre15.bat file, which is typically located in the following directory: \\Program Files\common\system\ado.
Warning: If you are using Microsoft Access as a database, you should not mark ADO as a free thread. In general, the ADO recordset must also be disconnected, and if you cannot control the site's ADO configuration (for example, you are a stand-alone software vendor [ISV], selling your WEB applications to customers and then managing their own configurations), it might be better not to cache the recordset.
The dictionary component is also a flexible object. LookupTable loads its data from a data file, and it is useful for combo box data and configuration information. The Pagecache object from Duwamish books provides the directory semantics, as does the performance of Caprock Dictionary. These objects or their derived objects can form the basis of a valid caching policy. Note that the Scripting.Dictionary object is not flexible, so it should not be stored in the application or session scope.
　　
　　 Tip 5: Do not cache a database connection in a application or Session object
Caching ADO connections is usually a bad strategy. If a Connection object is stored in application and used on all pages, all pages will compete to use the connection. If the Connection object is stored in the ASP session object, a database connection is created for each user. This will destroy the benefits of connecting pools and create unnecessary pressure on WEB servers and databases.
Instead of caching a database connection, you create and cancel an ADO object on each ASP page that uses ADO. This is a valid method because IIS has a built-in database connection pool. More specifically, IIS automatically enables OLE DB and ODBC connection pooling. This ensures that the connections on each page are created and canceled to be valid.
Because the connected recordset stores a reference to the database connection, you should not cache the connected recordset in the application or Session object. However, you can safely cache a disconnected recordset because it does not contain a reference to its data connection. To disconnect a recordset, perform the following two steps:
Set rs = Server.CreateObject ("ADODB.") RecordSet ")
Rs. CursorLocation = adUseClient ' 1th step
' Implanted record sets with data
Rs. Open strquery, Strprov
' Now disconnect the recordset from the data provider and the data source
Rs. ActiveConnection = Nothing ' 2nd step
For more information about connection pooling, see ADO and SQL Server (English) references.