CSP Gateway Configuration Guide - InterSystems Documentation

intersystems.com

CSP Gateway Configuration Guide - InterSystems Documentation

CSP Page Output Caching

retrieved from local storage (memory or local hard drive) rather than as a result of fetching the document from the original

server.

CSP Page Output Caching provides the option to maintain a cache of frequently accessed pages within the CSP Gateway.

Since the Gateway is a core component residing on the web server, its cache can be shared amongst all users of that CSP

installation. For example, if a single user requests a page that is configured to be placed in the Gateway cache, then all

subsequent requests for that page can use the cached copy. Cached pages are available to all users. This facility can have

a dramatic effect on performance for two reasons: Firstly, from a user’s perspective, pages retrieved from the cache are

served extremely quickly and, secondly, the Caché system is not involved in the delivery of cached pages so its work load

is significantly reduced.

The Page Output Caching facility implemented for CSP is based on the equivalent mechanism provided by Microsoft’s

ASP.NET product. This choice of design was made in order to reduce the amount of learning involved in getting to grips

with this facility. Most developers are familiar with ASP.NET.

Page caching is controlled by settings within the CSP %response object. Two properties are available for controlling which

pages should be cached and for how long. The default behavior of CSP is that pages should not be placed in the cache.

2.7.1 %response.Expires Property

The standard Expires property controls how long a page should reside in the cache.

For example, if a page is set to expire in one minute, the Gateway removes the page after it has resided in the cache for 60

seconds.

%response.Expires=[60 seconds time]

The equivalent ASP.NET directive would be:


2.7.2 %response.VaryByParam Property

This property allows you to control how many cached versions of the page should be created based on name-value pairs

sent through HTTP POST/GET. The default value is None. None implies that only one version of the page is added to the

cache, and all HTTP GET/POST parameters are simply ignored. The opposite of the None value is *. The asterisk implies

that all name-value pairs passed in are to be used to create cached versions of the page. The granularity can be controlled,

however, by explicitly naming parameters (multiple parameter names are separated using semicolons).

The use of the VaryByParam property is best illustrated by means of an example. Let's say we're building a web application

that is capable of displaying the weather forecast for the 50 United States. This application is completely encapsulated in

one page: Weather.csp.

Weather.csp presents the user with a drop-down list of states. A state is selected from the drop-down list and the value

of the state is sent back to Weather.csp. For example, State=WA or State=TX. For the sake of simplicity, let's assume

that we're using HTTP GET to send the data. Once an item (i.e. State) is selected, the request is sent to the server:

Weather.cspState=WA.

Let's assume that the forecast is only updated once a day and that there’s a significant overhead in generating the forecast.

We could add the following directives to the %response object of Weather.csp:

%response.Expires=[2 hours time]

%response.VaryByParam="State"

The ASP.NET equivalent would be:


CSP Gateway Configuration Guide 45

More magazines by this user
Similar magazines