Skills | Performance Tip 1: Cache frequently used data on a WEB server
A typical ASP page retrieves data from the back-end data store and then converts the results to Hypertext Markup Language (HTML). Retrieving data from memory is much faster than retrieving data from the back-end data store, regardless of the speed of the database. Reading data from a local hard disk is usually faster than retrieving data from the database. As a result, you can typically cache data on a WEB server (stored in memory or on a disk) to improve performance. Caching is a traditional way of exchanging time in space. If you're caching the right content, you can see a significant improvement in performance. For caching to be valid, data that is frequently reused must be saved, and a large (modest) overhead is needed to recalculate the data. If all of the cached data is stale, it can cause memory waste. Data that is infrequently changed is a good candidate for caching because you do not have to worry about synchronizing the data with the database over time. combo box lists, reference tables, DHTML fragments, Extended Markup Language (XML) strings, menu items, and site configuration variables, including data source names (DSNs), Internet Protocol (IP) addresses, and Web paths, are good candidates for caching. Note that you can cache the "representation" of the data without caching the data itself. If ASP pages are rarely changed and the cache is expensive (for example, the entire product catalog), you should consider producing HTML in advance, rather than showing it again in response to each request. Where should the data be cached, and what caching policies are there? Typically, data is cached on the WEB server's memory or disk.
Tip 2: Cache frequently used data in a application or Session object
ASP Application and Session objects provide a convenient container for caching data in memory. You can assign data to application and session objects, which remain in memory between HTTP calls. Session data is stored separately for each user, while application data is shared among all users. When will the data be loaded into the application or session? Typically, data is loaded when the application or session is started. To load data during the application or session startup process, add the appropriate code to either Application_OnStart () or Session_OnStart (). These functions should be in Global.asa, and if they are not, you can add them. You can also use the fashion function for the first time in Global.asa, and if not, you can add these functions. You can also mount the data the first time it is needed. To do this, add some code (or write a reusable script function) to the ASP page to check whether the data exists, and if not, load the data. This is a traditional performance technique, called lazy computing, that does not calculate a value until you know it is needed. For example, you can write a similar function for each block of data that you want. In what format should the data be stored? You can store any variant type, because all script variables are variant types. For example, you can store strings, integers, or arrays. Typically, you will store the contents of an ADO recordset as one of these variable types. To get data from an ADO recordset, you can manually copy the data to a VBScript variable, one field at a time. Using an ADO recordset Persistence function GetRows (), GetString (), or Save () (ADO 2.5) can be faster and easier. Under the appropriate conditions, you can cache the ADO recordset itself in the application or session scope. There are two warnings:
ADO must be marked as free thread
You must use a disconnected recordset.
If these two requirements are not guaranteed, do not cache the ADO recordset. In the following "non-agile components" and "Do not cache connections" techniques, we will discuss the dangers of storing COM objects in the application or session scope. When you store data in the application or session scope, the data remains there until you programmatically change it, session expiration, or the WEB application restarts. What if the data needs to be updated? To manually force updates to application data, you can access ASP pages that only administrators can access to update the data. Alternatively, you can automatically refresh the data periodically through functions. The following example stores a timestamp with cached data and refreshes the data after a period of time. It is not a good practice to cache large arrays in session[/b] or application objects. The syntax of the scripting language requires that the entire array be temporarily copied before any elements of the array are accessed. Arrays can be quickly traced and stored in memory as critical data pairs in the vicinity. Index A dictionary the peso is much slower to draw an array. Choose the data structure that provides the best performance for your situation.
Tip 3: Cache data and HTML on a WEB server's disk
Sometimes, there may be too much data to slow down in memory. "Too much" is just a saying, it depends on how much memory you want to consume, and how many items to cache and how often to retrieve them. In any case, if the data is too much memory, and the number of items to cache and how often to retrieve the items. In any case, if there is too much data to slow down in memory, consider caching the data in a text or XML file on the WEB server's hard disk. You can cache data in both disk and memory, creating the most appropriate caching strategy for your site. Note When you measure the performance of a single ASP page, retrieving the data on the disk may not necessarily be faster than retrieving data from the database. However, caching reduces the load on the database and on the network. In the case of high load, this can greatly improve overall throughput. This is useful when caching a large query result, such as a multiple-table join or a composite stored procedure, or a large result set. As always, try to test the pros and cons of several schemes. ASP and COM provide some tools for building disk-based caching schemes. The ADO recordset Save () and Open () functions hold and mount the recordset on the disk. You can use these methods to rewrite the code examples in the above application data caching techniques, replacing the code written in the Application object with the file's Save (). There are other components that can be used for files:
Scripting.FileSystemObject enables you to create, read, and write files.
The Microsoft®xml parser (MSXML) provided with Internet Explorer supports saving and loading XML documents.
LookupTable objects (for example, on MSN) are the best choice for loading a simple list from disk. Finally, you should consider caching the representation of the data on disk rather than the data itself. Pre-converted HTML can be stored on disk with. htm or. asp files, and hyperlinks can point directly to those files. You can automate the process of producing HTML using commercial tools such as Xbuilder, or the Microsoft®sql server™internet Publishing feature. Alternatively, you can place an HTML code fragment in an. asp file. You can also use FileSystemObject to read HTML files from disk, or to use XML for early conversion.
Tip 4: Avoid caching non agile components in a application or Session object
Although it is a good practice to cache data in a application or Session object, caching COM objects has a serious pitfall. Typically, people tend to cache COM objects that are often used in application or session objects. Unfortunately, many COM objects, including all Ession objects in Visual Basic 6.0 or later. Unfortunately, many COM objects, including all objects written in Visual Basic 6.0 or later, can cause serious bottlenecks when stored in application or session objects. Specifically, when any of the less agile components are cached in session or application objects, performance bottlenecks are caused. An agile component is a component that is marked as Threadingmodel=both, which aggregates free-threaded marshaler (FTM) or a component that is marked as threadingmodel=neutral. (The Neutral model is a new model for windows®2000 and COM +.) The following components are not agile:
Free-threaded components (unless they aggregate FTM).
The unit thread component.
Single threaded component.
The configured components (Microsoft Transaction Server (MTS)/com+ libraries and server packages/applications) are not agile unless they are Neutral threads. The unit thread component and other non agile components are most appropriate within the page scope (that is, they are created and destroyed on a single ASP page). In IIS 4.0, components marked as Threadingmodel=both are considered agile. In IIS 5.0, this is not enough. Components must not only be marked Both, but must also gather FTM. The article on agility describes how to get the C + + components written in Active Template Library to gather FTM. Note that if the component caches interface pointers, the pointers themselves must be agile or must be stored in the COM Common Interface table (GIT). If you cannot recompile the Both thread component to aggregate FTM, you can mark the component as threadingmodel=neutral. Alternatively, if you do not want IIS to perform an agile check (so you can allow non-agile components to be stored in the application or Session scope), you can set asptrackthreading Model to True in the configuration database. Changing AspTrackThreadingModel is not recommended. IIS 5.0 will have an error if you want to store the Server.CreateObject components created in the Application object. You can use this to avoid this error in Global.asa, but it is not recommended because it leads to aggregation and serialization, which is described below. What happens if you cache a component that is not agile? Ease sets and serialization, which is described below. What happens if you cache a component that is not agile? Sustained
Non-agile components that exist in the session object lock the session to the ASP worker thread. ASP maintains a worker thread pool to handle requests. Typically, a new request is always handled by the first worker thread that is available. If the session is locked in a thread, the request must wait until its associated thread is available.
Storing non agile components in the application scope has even worse performance impact. ASP must create a special thread to run stored in
Application the non-agile components in the scope. There are two results: All calls must be pooled to this thread, and all calls are queued up. "Pooling" means that the parameters must be stored in the shared area of memory, a costly context switch to a particular thread is executed, a method of executing the component is pooled, the result is aggregated into a shared area, another costly context switch is performed, and control is returned to the original thread. Serialization means running only one method at a time. Two different ASP worker threads cannot execute multiple methods on a shared component at the same time. This eliminates concurrency, especially on multiprocessor computers. Worse, all non agile application scoped components share a single thread (the host STA), so the impact of serialization is even more pronounced. Alternative Here are some general rules. If you are writing objects using 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 objects that are not agile, you should create and release them on each page. Objects run directly on the ASP worker thread, so they are not pooled or serialized. If COM objects run on IIS servers, and if they do not take a long time to initialize and delete, performance is acceptable. Note single-threaded objects should not be used in this way. Be careful-VB can create a single-threaded object! If
