This chapter provides an overview of portal caching and discusses how to:
Administer server-based caching.
Administer browser-based caching.
Administer web server-based navigation caching.
Information on your PeopleSoft portal that changes frequently must be regularly updated, but for best efficiency, information that remains static should be cached for quick retrieval. Information that changes less frequently should be updated on a more deliberate schedule. The composition of changing and static information varies depending on the user, role, application, portal, web server, information structure, and information content involved.
Caching Configuration Options
When properly configured, caching significantly boosts portal performance. PeopleSoft portal technology provides a wide range of caching options. These options target different elements of the portal environment, use a variety of criteria for applying caching, and have varying degrees of scope. Not all caching options apply to all circumstances.
You can target portal caching to a specific pagelet, template, portal, or web server. You can also apply caching based on the content reference type or browser type. In some cases, you can specify the scope of caching to be by user, by role, or by application.
Some types of caching take place on the portal web server, and others are applied at the browser without requiring individual browser configuration. You can make various caching settings in the Web Profile Configuration component (WEB_PROFILE), on a personalization page, or in a template HTML element.
With server caching, the cached data is stored on the portal web server. When a user's browser requests a piece of information from the portal, the server transmits the currently available data. The currency of the data provided depends on whether the server has refreshed the data since the last request. This is controlled by the server-based caching criteria that you defined for that data, such as a time interval or a specified number of requests.
Note. When browser caching is enabled, you can manually refresh the browser, which reloads the entire browser HTML content from the portal server. This doesn't update the information that's cached on the server, however.
Default Homepage Caching
The default homepage is automatically cached on the server, but only when you select the Allow Public Access check box in the Public Users group box of the Web Profile Configuration - Security page. Caching the default homepage according to these rules protects the server from having to regenerate the same homepage repeatedly. This is useful for guest sign-in scenarios.
Configuring Portal Security
Enterprise PeopleTools 8.50 PeopleBook: PeopleCode Language Reference
This section provides an overview of caching scope and discusses how to:
Implement target content caching.
Implement pagelet caching.
Implement metadata caching.
You can define caching for server-based portal content with one of three levels of scope:
This is also known as the user scope. The portal maintains the cached content independently for each user. This scope is useful when the content that is displayed, such as a 401K balance, is specific to the user who's signed in.
Each user is assigned one or more roles. The portal maintains a single cache of the content for all users with a given combination of roles. This scope is useful when the content that is displayed, such as the menu structure, is specific to the role set of the user who’s signed in. If your user population has many unique role combinations, your caching memory requirements may be nearly the same as private scope caching.
This is also known as the application scope. The portal maintains a single cache of the content for all users who are using a given application. This scope is useful when all users who have access to this content, such as company news articles, bulletins, or messages, see the same thing. Because only one cache object is managed in memory for your entire user population, this is the least memory-intensive scoping option.
You can cache the content of an individual target by specifying several caching parameters in the HTML of each locally defined template that invokes the target. You must also enable target content caching for the portal.
Important! Target content is cached in memory on the web server. If you use this feature excessively, the cache could consume all available memory. Use target content caching only to cache content that is static or doesn't require constant updating and that is accessed frequently by many users.
Specifying Caching Parameters
You apply target content caching by inserting a Cache element inside a TargetContent element in the HTML of a locally defined template.
The Cache element has these attributes:
Use one of these values:
Specify the number of seconds that should pass before the portal refreshes the target content cache.
This example shows caching that is defined with the application scope and an interval of 1200 seconds:
<TargetContent Name="MyContent"> <Cache Scope="application" Interval="1200">ANY</Cache> </TargetContent>
Note. The Cache element must not be empty, but its content can be anything.
Enabling Target Content Caching
Any Cache elements that you insert in template HTML are ignored by the portal unless you enable target content caching globally for the portal. Select the Cache Target Content check box in the On the Web Server group box of the Web Profile Configuration - Caching page.
Working with Portal Templates
If you're developing a pagelet and you know that its content will remain static for all users, you can specify the application or public scope. If you know that the pagelet's content will remain static for all users with the same role, you can specify the role scope. However, if the pagelet content is static only for individual users, you must specify the user or private scope. If you're not the pagelet developer, you probably won't know when the pagelet content will change, so to be sure you must specify the user scope.
Important! Pagelet content is cached in memory on the web server. If you use this feature excessively, the cache could consume all available memory. Use pagelet caching only to cache content that is static or doesn't require constant updating, and is accessed frequently by many users.
You can cache the content of an individual pagelet by specifying caching parameters in one of these locations:
The HTML of any locally defined template that invokes the pagelet.
A content reference attribute in the pagelet definition.
Note. If you specify caching parameters for a pagelet in both locations, the caching parameters in the template take precedence, and the caching parameters in the content reference attribute are ignored.
The presence of the caching parameters is sufficient to enable caching for the associated pagelet; no additional setting is required. To disable pagelet caching, delete the caching parameters.
Specifying Pagelet Caching in the Template
You apply pagelet caching in a template by inserting a Cache element inside a Pagelet element or IClientComponent element in a locally defined template.
The Cache element has these attributes:
Use one of these values:
Specify the number of seconds that should pass before the cache expires and is subject to an automatic refresh. This value depends on the frequency with which the data changes, and the need for data to be 100-percent accurate.
For example, a company news article rarely changes once it’s been published. You might want to set the refresh period for the article pagelet to be 86400 seconds so that it's cached for a 24-hour period.
This example shows caching that is defined in an IClientComponent element with the role scope and an interval of 1800 seconds:
<IClientComponent Name="Header"> <Cache Scope="role" Interval="1800">ANY</Cache> <Source Product="Portal">ICType=Script...</Source> </IClientComponent
Note. The Cache element must not be empty, but its content can be anything.
Specifying Pagelet Caching in the Content Reference
You apply pagelet caching in a template by defining a special content reference attribute on the pagelet definition.
To implement caching for a pagelet:
In PeopleSoft Pure Internet Architecture, open the content reference administration page of the pagelet you want to cache.
Navigate to PeopleTools, Portal, Structure and Content, Portal Objects, Pagelets, select the folder containing the pagelet, and edit its content reference.
Add a new content reference attribute.
Specify the attribute name and label.
In the Name field, enter PSCACHECONTROL.
In the Label field, enter PSCache-Control.
Specify the attribute value with this syntax:
Use one of these values:
Specify the number of minutes that should pass before the cache expires and is subject to an automatic refresh.
For example, consider a PeopleSoft Enterprise Portal environment in which users can personalize their company news pagelet. The articles don't change frequently, and users don't need them to be up-to-the-minute; therefore, you might specify private caching with a three hour (180 minute) expiration:
Save the content reference.
The next time a user signs in and displays the pagelet, the caching that you specified takes effect.
Managing Caching of Personalizable Pagelets
You can make it possible for users to personalize their homepage pagelets. When a user personalizes a pagelet, the result should be visible only to that user, and therefore should be cached only for that user. To achieve this goal, as soon as the user attempts to personalize the pagelet, regardless of the caching scope that you originally specified, the portal automatically changes the caching scope to apply on a private basis and maintains the cached pagelet independently for that user.
Important! This automatic scope change applies only to the
user who is personalizing the pagelet and to the portal on which the pagelet
is personalized. On other portals, and for other users, the originally defined
caching scope for that pagelet still applies. If the personalizations aren't
stored as portal-specific data, then the personalizations for a pagelet that
was originally defined with a wider caching scope can become visible to others
who are accessing the same site through another portal.
Therefore, when developing personalizable pagelets, it's important to ensure that stored pagelet personalization metadata is keyed by both user ID and portal name, so that you can populate the pagelet independently for each portal. This prevents user personalizations on one portal from being cached and visible to a larger audience on another portal.
Disabling Manual Pagelet Refresh
When you implement pagelet caching, a refresh button appears by default in the pagelet header. You can prevent users from refreshing the pagelet manually by hiding the refresh button, which you do by using a check box on the pagelet's content reference administration page.
Administering Content References
Managing Pagelet Attributes
Understanding Caching Scope
Enterprise PeopleTools 8.50 PeopleBook: Using PeopleSoft Applications
PeopleSoft Enterprise Portal 9.1PeopleBook: Enterprise Portal Application Technology
Metadata caching is governed by portal-wide properties that control caching for these portal metadata objects as a group:
The portal registry.
Locally defined templates.
Portal metadata is likely to change far less frequently than pagelets or target content, so caching it on the server is an easy way to improve portal performance. Caching improves system performance by decreasing service requests from the web server to the application server.
Note. Metadata caching always applies with the application scope—the portal maintains a single metadata cache for all users who are using an application.
You implement metadata caching for a portal by setting these properties in the On the Web Server group box of the Web Profile Configuration - Caching page:
Select to enable metadata caching.
Metadata caching is enabled by default. You must restart the web server or wait for the stale interval to expire when you change:
Note. When you add or delete a content reference or folder, this change shows up in the menu structure immediately, because it's rendered within the application server, not the portal servlet.
Specify the number of seconds that should pass before the portal refreshes the metadata cache.
The default value of this property is 86400 (24 hours). With this setting, if you change the default local node in the database, the change doesn't take effect until the following day.
Set to the maximum total number of HTTP requests that the web server should receive for objects in the metadata caches of all portals. When the web server receives this number of hits, it purges all metadata caches, forcing the portals to refresh them.
This setting enables you to manage application server memory consumption. If the web server is consuming too much memory, you can lower this value. This causes the web server to reclaim the memory that is used for cached portal objects more often. The cost of this is increased CPU usage on both the web and the application server when the web server deletes the cached objects and then retrieves them again from the application server.
The default value of this property is 1000. Set to –1 to disable the feature.
Note. The timing properties—the cache stale interval and the cache purge all hit count—compete for effect. The first timing property to reach the specified interval or number of hits takes precedence. When the metadata cache on a portal is refreshed, the cache stale interval and cache purge all hit count counters for all portals on the same web server are reset.
This section provides an overview of browser-based caching and discusses how to:
Implement homepage caching.
Control navigation pagelet caching.
Implement PeopleSoft page caching.
A modern web browser can cache the information that it receives from a web server in several ways. Its preference settings determine how much storage space to use for caching, as well as the criteria by which it should refresh its cache.
How the Portal Controls Browser-Based Caching
If the browser is accessing a straight HTML page, it caches the page as a whole. If it's accessing a frameset, it caches the individual frames in the frameset, so that each frame's content can be refreshed independently.
Rather than depend on users to enable and set the timing criteria for caching, PeopleSoft portal technology takes advantage of a feature of HTTP. The portal web server can specify a caching interval in the HTTP response header of the HTML page or frame content that it delivers. The browser applies this value to determine when to stop using its cached copy of the data and request the most recent version from the server.
Note. Even when the browser requests a fresh copy of an HTML page or frame content, the portal web server controls whether the content it sends is cached data or fresh data, based on its own caching settings.
When to Disable Browser-Based Caching
The caching system increases system response performance in typical production environments, in which users access the portal web site by using computers that have been assigned specifically to them or computers that they own. However, some environments don't conform to this scenario.
You should consider disabling browser-based caching in these environments:
Any environment where multiple users access the same computer.
These include kiosk-type environments, as well as corporate hoteling environments, where multiple users access the same machine. Users might access the same machine within minutes of each other, before the browser cache for the previous user times out. Security is enforced in this situation, but the new user may be confused by an inability to access certain items.
A development or testing environment.
As content references are created or changed for a portal during development or testing, the new data might not appear to be immediately available due to caching.
Any environment where you are using web server-based navigation caching.
In a PeopleSoft portal, a homepage is a combination of portal content elements that are assembled by the portal and delivered as a single HTML page, which is cached on each user’s browser.
Based on the configuration that you specify, the portal enables or disables homepage caching by using the homepage's HTTP header. If caching is enabled, the header also conveys the time interval before the web server is accessed again to get a fresh homepage. The browser does not access the web server after it initially receives the homepage until the specified interval elapses. You can also specify whether a particular browser model and version should use or ignore the caching information in the header.
In any case, if a user clicks the browser’s Refresh button, the homepage is accessed from the web server again, overwriting the homepage that is cached on the browser and restarting the interval counter. If any of the content is cached on the web server, the browser is refreshed from the server cache.
Enabling Homepage Caching
You enable homepage caching for a site by selecting the Cache Homepage check box in the On the Browser group box of the Web Profile Configuration - Caching page. When this check box is selected (the default value), two related page elements become editable:
Homepage Stale Interval.
Specifying the Homepage Stale Interval
Specify the homepage caching interval for a site by entering a value in seconds in the Homepage Stale Interval field in the On the Browser group box of the Web Profile Configuration - Caching page. When the specified interval elapses, the browser sends a new request for the homepage to the portal web server the next time a user accesses the homepage. The default value for this field is 1200.
Disabling Caching for Selected Browsers
Because browsers don't all process HTML in exactly the same way, you might find it necessary to disable homepage caching for selected browser versions. This can be useful if you have one or two supported browsers and want to disable caching for nonstandard browsers that could pose an administration problem.
To disable homepage caching for a browser version, add a row to the Browsers grid of the Web Profile Configuration - Caching page, enter the browser's user agent ID, and select the Cache Home Page check box for that row. Homepage caching is enabled for all browser versions except those with this check box cleared, regardless of whether they're listed in the grid.
Note. As a convenience, several well-known browser types are included as example rows in the configuration. All of the examples have homepage caching enabled by default.
When you use the portal menu to access target content other than your homepage, the portal delivers that content within a frameset. The portal header, menu, and target content regions are independent and can be managed separately by the browser. The menu region contains the portal's navigation pagelet, which can be cached on the browser with the user scope.
Without caching, every time the user clicks a menu folder, the browser requests a new copy of the navigation pagelet from the portal web server, which can significantly affect performance. With caching, the browser saves all of the menu states that are generated by user activity and can immediately restore them on demand.
Users manage navigation pagelet caching by using the Time page held in cache personalization option to specify a caching interval.
To specify a caching interval:
In PeopleSoft Pure Internet Architecture, select My Personalizations.
On the Personalizations page, click the Personalize Option button for general options.
Enter an override value in minutes for the Time page held in cache option and click OK.
The default value of this option is 900 minutes. To disable navigation pagelet caching, specify a value of 0 minutes. The maximum value can be 525600 minutes, which is one year.
Note. For the new setting to take effect, you must delete
the browser cache.
With caching in effect, any changes in the menu structure while the user is signed in to the portal aren't available until the user signs out and back in, or until the caching interval elapses.
PeopleSoft pages are application pages that appear in the target content region of the portal frameset.
Being able to control PeopleSoft page caching on the browser is useful for situations in which PeopleSoft applications are deployed to kiosk workstations where multiple users access the applications. Disabling caching means that users can't click the browser's Back button to view another person's transaction or to view any other sensitive data.
Enabling PeopleSoft Page Caching
You enable PeopleSoft page caching for a site by selecting the Cache Generated HTML check box in the On the Browser group box of the Web Profile Configuration - Caching page. PeopleSoft page caching is enabled by default.
With PeopleSoft page caching disabled, when users click the Back button they receive a data missing message in Netscape Navigator and a page expired message in Microsoft Internet Explorer.
Note. The side effect of turning off caching completely is degraded performance. For each new page, the system calls the database. However, PeopleTools offers a compromise related to browser caching in the form of navigation pagelet caching, which doesn't expose any sensitive information.
See Controlling Navigation Pagelet Caching.
Specifying Supported States
When the browser caches a PeopleSoft page, it stores the state of that page, including any unsaved changes. With the page state in the cache, users clicking the browser's Back button see the cached page in the state that it was in when they last viewed it. The browser caches as many page states as its own settings for storing temporary data allow.
The portal also maintains its own cache of page states for each browser window. You can specify how many of these states the portal should consider valid and support for further interaction. This setting, combined with the number of states the browser maintains, determines whether users can continue to work with previously accessed page states.
For example, if you specify that the portal should support two states, and the user clicks the Back button three times, any activity that requires refreshing the displayed page from the web server (such as field validation) fails, producing a page unavailable message in the browser.
You specify how many states the portal should support by entering a number in the Number of States Supported field in the On the Browser group box of the Web Profile Configuration - Caching page. The default value of this field is 5 states.
Configuring Portal Security
This section provides an overview and discusses how to implement web server-based navigation caching.
Web server-based navigation caching considerably boosts performance by automatically storing cached data on the web server as users select items from the navigation menu. This form of caching saves unnecessary calls to the application server.
The portal maintains a single cache for all users with a given combination of roles. If your user population has limited role combinations, your caching memory requirement is significantly reduced.
See Understanding Caching Scope.
Implement web server-based navigation caching by selecting the Cache Menu check box in the On the Web Server group box of the Web Profile Configuration - Caching page.
Note. This is the default setting for the DEV and TEST web profiles.
The cached data is stored in the following folder and cannot be moved:
You must delete the cache periodically to keep the folder at a manageable size.
To prevent conflicts, disable browser-based caching and homepage caching.
To disable browser-based caching:
Select PeopleTools, Personalization, Personalization Options.
Select the PeopleTools (PPTL) option category level.
Remove the METAXP personalization definition.
To disable homepage caching:
Select PeopleTools, Web Profile, Web Profile Configuration.
Select the appropriate web profile.
Access the Browsing grid on the Caching page.
Clear the Cache Homepage check box for the appropriate browser.