Learn how to speed up your ASP application performance by utilizing caching techniques with the Simplewire? SMS Software Development Kit.
Using the Application Object to Improve Performance
5/11/2001
Introduction
Companies using Web services sold by application service providers (ASPs) are expected to increase nearly 250 percent by 2004, according to the Phillips Group (see http://www.networkcomputing.com/1125/1125service1.html). Substantial portions of those Web services provide Application Programming Interfaces (APIs) to their services via the Internet. While these services are convenient and easy to use, they also dramatically increase network traffic and potentially slow down application performance. Despite the potential slowdown, most customers simply execute a round-trip request for every one of their incoming requests.
While pulling fresh data for every incoming request is the easiest solution, it is not always the most scalable or robust method. Using persistence on the server to cache either the data or final HTML can impressively reduce the number of round-trip requests to the Web service, and thereby increase performance. It is much faster for a Web application to process a client's request using data that's close at hand, as opposed to reading and writing live data across the Internet.
ASPs and server-to-server data exchanges unveil new opportunities for developers to optimize their code and scale their solution. However, even in this light of new opportunity, developers must still take heed in optimizing their code using the Application object. In ASP scripting, as in any other programming language, it is important to determine which areas of the application are consuming the most time and resources. This information can then be used to efficiently target the critical areas for optimization. This article will discuss what types of data exchanges are targets for optimization and the benefits and disadvantages of using persistence with the Application object.
Persistence in ASP
Persistence signifies the storing of information in such a way that it can be repetitively accessed. Web developers will usually persist data in memory or in a database. However, for our illustration, data persists on the application service provider's (ASP's) network and customers access the data over the Internet. Each method has its own benefits and disadvantages, which will be discussed later in the article.
If the developer chooses to persist the data in memory, the natural choice in ASP is to use session or application variables. The server maintains one Application object for each ASP-based application. The object is initialized when the application is accessed by the first user and then persists until the application is shut down. When the variables are defined in the server's Application object, their values are available to all pages in the application. An application hit counter, which is updated for each new user session, is a common example of this concept.
To allow the Application object to function in ASP, a single file named global.asa is used for each "application." This file resides in the application root directory on the server. This directory contains the specific files that account for the application. Any subdirectories of the main application directory are also part of the application. Due to this confusion, developers need to be aware of the possibility of overlapping applications, and should generally create separate directories for each application. When an application in ASP is discussed, it is implied that all the files are included in the same directory as global.asa and any of its subdirectories. Application events only occur when a client retrieves an ASP page-they are not triggered for a static HTML page.
When To Use Persistence
When a developer designs a persistence scheme, they typically make a copy of all frequently used data items and store them in a place that provides faster access. As long as the real data items (that live in the Web service) and the copies (that live on the Web server) stay in sync, consistency can be maintained. Unfortunately, when such data changes, issues of congruity are introduced. For example, if a Web service updates its information, then the copy on the Web server will become inconsistent. However, if the data on the Web server remains usable after 1 minute or even 1 day, then persistence can be achieved. If the copies on the Web server need to be propagated to the Web service, then persistence may not be an option. In such an instance, a problem will occur if the application attempts to update information that no longer exists on the Web service. It is much easier to design a persistence scheme for read-only data, rather than data that's updated over the lifetime of an application.
Let's review an actualized illustration of designing a persistence scheme for a Web application that uses a Web service. One application service provider, Simplewire, provides a text-messaging platform over the Internet. Simplewire delivers a service that allows customers to query its interface for a list of wireless carriers. While the length of the carrier list is relatively small (about 80 to 400 carriers), its size exponentially grows since each wireless carrier contains nearly 20 properties. Imagine generating a Web page that displays this carrier list to your users. Persistence begins to manifest after realizing that this information will only periodically change. The application, in turn, gains an impressive performance boost. In addition to locally storing the data, caching the final HTML that is sent to the browser provides further improvement. In fact, initial tests conducted with Simplewire affirmed a 110 percent performance boost.
Persistence also improves reliability. Simplewire offers multiple servers on the Internet to access its service. With the implementation of code and the inclusion of timestamps, the Application object is capable of storing detailed information such as servers that are available and servers that provide the fastest performance.
Advantages of Using Persistence
Persistence offers a very inexpensive method for gaining faster server performance. Querying for data across the Internet decelerates applications and thus degrades application performance. Data that follows the guidelines to persistence allows the information to remain as close as possible to the end client.
The possibility of persistence increasing your application's reliability is dependent on the nature of the application and the services offered by your ASP. To resolve this very conflict, Simplewire offers two Internet sites for its service. If one site fails, then an Application variable is set to direct future requests to the other site.
Persistence could also decrease network traffic, particularly if a substantial amount of data is queried from the Web service. The data could already be prepared for presentation if the final HTML is stored, rather than the raw data.
Disadvantages of Using Persistence
Although persistence offers improved performance, it still has a few drawbacks. Developers should be aware that caching large arrays in Application objects is generally not a good idea. Before accessing any element of the array, the semantics of the scripting languages require that a temporary copy of the entire array be made. For example, if a developer persists a 100,000-element array of strings that maps U.S. zip codes to local weather stations in the Application object, ASP must first copy all 100,000 weather stations into a temporary array before it can extract just one string.
Besides taking note of complications associated with large arrays, developers should also be aware of the threading model used by any components in the application scope. Any threading model used to develop the component will have significant impact on whether the component instance should be assigned to a variable in one of the Application collections. In fact, only components that support both Free and Apartment threading models can have application scope (see more on Microsoft site). In this case, it might be more useful to cache the final HTML instead of the object.
When storing an array in an Application object, a developer should not alter the elements of the stored array directly. The following script demonstrates this inoperability:
<% Application("MyArray")(3) = "new value" %>
This problem arises when the Application object is implemented as a collection. The array element MyArray(3) does not receive the new value. Instead, the value would be included in the Application object collection and would overwrite any information that had previously been stored at that location.
Examples
The following example will refresh the HTML stored in an Application variable every ten seconds. The "UPDATE_INTERVAL" value could be easily changed to refresh the Application object as often as necessary. Every refresh will query Simplewire's network for a carrier list and store the HTML needed to build a select box. The testing of this code demonstrated 110-percent faster application performance.
<% ' Set refresh interval in seconds
Const UPDATE_INTERVAL = 10
' Function to fetch carrier list
Function FetchCarrierList()
Set SMS = Server.CreateObject("Simplewire.SMS")
SMS.CarrierListSend
Set FetchCarrierList = SMS.CarrierList
Set SMS = Nothing
End Function
' Function to return the carrier list
Function GetCarrierList()
' Call function to see whether the list
' needs to be updated.
UpdateCarrierList()
' Set carrier list
GetCarrierList = Application("CarrierList")
End Function
' Function that checks timestamp to see whether
' the list needs to be updated
Sub UpdateCarrierList
Dim tmp, strLastUpdate, HTML
' Retrieve last update timestamp
strLastUpdate = Application("LastUpdate")
' Decide if object needs updating
If (strLastUpdate = "") Then
update = True
ElseIf (UPDATE_INTERVAL < DateDiff("s", strLastUpdate, Now)) Then
update = True
End If
If (update) Then
Set tmp = FetchCarrierList()
' Update the Application object
Application.Lock
' Generate HTML
HTML = ""
For Each carrier in tmp
HTML = HTML & ""
Next
Application("CarrierList") = HTML
Application("LastUpdate") = Now()
Application.Unlock
End If
End Sub
%>
It is also possible to initialize the Application object at startup, rather than on the first data request. Using the global.asa file, a developer would write a handler for the Application_OnStart event, setting the initial values for each wanted variable.
<% Sub Application_OnStart()
' Initialization code....
End Sub
%>
Summary
Using the Application object within your ASP code offers potentially improved application performance. Depending on the type of data used, persistence can offer improved application response time, while providing the same level of functionality. Review those parts of your application that use round-trip requests to grab data, and then implement the Application object to dramatically increase its speed.
