Page Caching Options

Related topics

Option

Description

Cache Page Definition Only

Creates a cached copy of the page definition only. The page definition includes:

Metadata describing the page structure

Identification of the portlets the page contains

Items that exist on the page

Style information for the page

Notes:

One copy of the page definition is cached for each user, which can impact storage and performance. Choose this option for pages with highly dynamic content.

This option eliminates the regenerating of the page definition, but does not eliminate portlet validity checks (for validation-based portlets), portlet content retrieval (for expired or invalid portlets), or page assembly. Portlet validity (for validation-based portlets) is checked on each request, unlike expiry-based caching, which only performs these checks when the page has expired. Therefore, this option should only be used when the page contains portlets that must use validation- or invalidation-based caching, or that have short expiry periods.

When this caching option is selected, the page definition will be cached in both Web Cache and the Portal Cache. If the Web Cache entry is invalidated, the Parallel Page Engine will contact the portal to see if the Portal Cache contains the newest version of the page definition. If the cached definition is valid, the Parallel Page Engine will use the Portal Cache entry to assemble the page. If the Portal Cache entry is not valid, the page definition will be regenerated and both cache entries will be refreshed. Generating the page definition is a CPU-intensive operation that occurs in the Portal database, so either type of caching will help reduce the load on the database.

This option is only available for Standard, Mobile, and JSP pages.

Cache Page Definition And Content For [ ] Minutes

Creates a cached copy of the page definition (as described in the previous option), and caches the assembled page's content, including the rendered content of all portlets, for a specified period of time. This is called expiry-based caching.

Notes:

Choose this option for pages with more static content that is unlikely to change within the specified time period.

With expiry-based caching, the fully assembled page is cached in the Portal Cache. Portal also instructs the browser to cache the page. Web Cache is not used to cache the fully assembled page; since only session specific pages can be cached in Web Cache (for security reasons), it would be redundant to cache a page there in addition to caching it in the browser.

Expiry-based caching ignores the caching options for the individual portlets on the page, so it is possible that some content will be stale when the page is viewed from the cache. However, this option eliminates the need for the page to be dynamically assembled with every request, so it is the best choice for minimizing the load on the Parallel Page Engine and Portal middle-tier servers. The Parallel Page Engine always checks the validity of a page definition before serving a page. Therefore, if the page definition changes, Portal ensures that the page will be regenerated even if it has not expired.

If you select this option, you can include a Refresh link on the page. You can use this link to refresh the page by regenerating it from the database. Only users with the appropriate privileges can use this link. Other users will not see this link.

This option is only available for Standard and Mobile pages.

Cache Page Definition Only At System Level

Creates a single cached copy of the page definition (as described in the first option) for all users. The page definition will be the same for all users. Although this option greatly reduces storage requirements and improves performance, page customizations are not possible given that the page is the same for all users. Consequently, the Customize link and all other customization controls are disabled.

Notes:

Choose this option for pages with highly dynamic content, but only when the ability to customize the page is not required.

Caching at the system level places a single copy of the page's structure in the system cache for all users. Consequently, all page customization options are disabled.

With this option, a single copy of the page definition is used to build the page for all users. For this reason, all of the page's links, tabs, and items will be displayed to all users. However, users can still only perform the actions for which they have the appropriate access privileges. For example, if a user does not have the appropriate privileges to access a particular tab, the user will receive an error message when the user clicks the tab.

This option is only available for Standard, Mobile, and JSP pages.

Cache Page Definition And Content At System Level For [ ] Minutes

Creates a single cached copy of the page definition (as described in the first option) for all users, and caches the assembled page's content at the system level, including the rendered content of all portlets, for a specified period of time. This is called expiry-based caching. Although this option greatly reduces storage requirements and improves performance, page customizations are not possible given that the page is the same for all users. Consequently, the Customize link and all other customization controls are disabled.

Notes:

Choose this option for pages with more static content that is unlikely to change within the specified time period, but only when the ability to customize the page is not required.

Caching at the system level places a single copy of the page's structure and content in the system cache for all users. Consequently, all page customization options are disabled.

With this option, a single copy of the page is displayed to all users. For this reason, all of the page's links, tabs, and items will be displayed to all users. However, users can still only perform the actions for which they have the appropriate access privileges. For example, if a user does not have the appropriate privileges to access a particular tab, the user will receive an error message when the user clicks the tab.

If you select this option, you can include a Refresh link on the page. You can use this link to refresh the page by regenerating it from the database. Only users with the appropriate privileges can use this link. Other users will not see this link.

For this option, the page runs as a public user for portlets and does not use security for items. Items are displayed, but are only accessible by users who have the appropriate privileges for the items. Portlets only display public content.

This option is only available for Standard and Mobile pages.

Don't Cache

Disables page caching.

Notes:

The use of this option may adversely impact portal performance.

Dynamic page generation can affect the performance of your portal by placing a heavy load on both the database and the middle-tier. However, you may want to disable page caching in the following circumstances:

Your page contains PL/SQL items or URL items that are rendered in place (i.e., displayed directly on the page) and that produce dynamic content that must always be up-to-date (a portlet that is not cached or that uses a short expiry would be a better choice for this kind of content).

You are concerned that a soft-invalidation event, such as a change to user group membership, may result in a cached version of a page being viewed by an active user who has recently lost his privileges on the page.

Option	Description
Cache Page Definition Only	Creates a cached copy of the page definition only. The page definition includes: Metadata describing the page structure Identification of the portlets the page contains Items that exist on the page Style information for the page Notes: One copy of the page definition is cached for each user, which can impact storage and performance. Choose this option for pages with highly dynamic content. This option eliminates the regenerating of the page definition, but does not eliminate portlet validity checks (for validation-based portlets), portlet content retrieval (for expired or invalid portlets), or page assembly. Portlet validity (for validation-based portlets) is checked on each request, unlike expiry-based caching, which only performs these checks when the page has expired. Therefore, this option should only be used when the page contains portlets that must use validation- or invalidation-based caching, or that have short expiry periods. When this caching option is selected, the page definition will be cached in both Web Cache and the Portal Cache. If the Web Cache entry is invalidated, the Parallel Page Engine will contact the portal to see if the Portal Cache contains the newest version of the page definition. If the cached definition is valid, the Parallel Page Engine will use the Portal Cache entry to assemble the page. If the Portal Cache entry is not valid, the page definition will be regenerated and both cache entries will be refreshed. Generating the page definition is a CPU-intensive operation that occurs in the Portal database, so either type of caching will help reduce the load on the database. This option is only available for Standard, Mobile, and JSP pages.
Cache Page Definition And Content For [ ] Minutes	Creates a cached copy of the page definition (as described in the previous option), and caches the assembled page's content, including the rendered content of all portlets, for a specified period of time. This is called expiry-based caching. Notes: Choose this option for pages with more static content that is unlikely to change within the specified time period. With expiry-based caching, the fully assembled page is cached in the Portal Cache. Portal also instructs the browser to cache the page. Web Cache is not used to cache the fully assembled page; since only session specific pages can be cached in Web Cache (for security reasons), it would be redundant to cache a page there in addition to caching it in the browser. Expiry-based caching ignores the caching options for the individual portlets on the page, so it is possible that some content will be stale when the page is viewed from the cache. However, this option eliminates the need for the page to be dynamically assembled with every request, so it is the best choice for minimizing the load on the Parallel Page Engine and Portal middle-tier servers. The Parallel Page Engine always checks the validity of a page definition before serving a page. Therefore, if the page definition changes, Portal ensures that the page will be regenerated even if it has not expired. If you select this option, you can include a Refresh link on the page. You can use this link to refresh the page by regenerating it from the database. Only users with the appropriate privileges can use this link. Other users will not see this link. This option is only available for Standard and Mobile pages.
Cache Page Definition Only At System Level	Creates a single cached copy of the page definition (as described in the first option) for all users. The page definition will be the same for all users. Although this option greatly reduces storage requirements and improves performance, page customizations are not possible given that the page is the same for all users. Consequently, the Customize link and all other customization controls are disabled. Notes: Choose this option for pages with highly dynamic content, but only when the ability to customize the page is not required. Caching at the system level places a single copy of the page's structure in the system cache for all users. Consequently, all page customization options are disabled. With this option, a single copy of the page definition is used to build the page for all users. For this reason, all of the page's links, tabs, and items will be displayed to all users. However, users can still only perform the actions for which they have the appropriate access privileges. For example, if a user does not have the appropriate privileges to access a particular tab, the user will receive an error message when the user clicks the tab. This option is only available for Standard, Mobile, and JSP pages.
Cache Page Definition And Content At System Level For [ ] Minutes	Creates a single cached copy of the page definition (as described in the first option) for all users, and caches the assembled page's content at the system level, including the rendered content of all portlets, for a specified period of time. This is called expiry-based caching. Although this option greatly reduces storage requirements and improves performance, page customizations are not possible given that the page is the same for all users. Consequently, the Customize link and all other customization controls are disabled. Notes: Choose this option for pages with more static content that is unlikely to change within the specified time period, but only when the ability to customize the page is not required. Caching at the system level places a single copy of the page's structure and content in the system cache for all users. Consequently, all page customization options are disabled. With this option, a single copy of the page is displayed to all users. For this reason, all of the page's links, tabs, and items will be displayed to all users. However, users can still only perform the actions for which they have the appropriate access privileges. For example, if a user does not have the appropriate privileges to access a particular tab, the user will receive an error message when the user clicks the tab. If you select this option, you can include a Refresh link on the page. You can use this link to refresh the page by regenerating it from the database. Only users with the appropriate privileges can use this link. Other users will not see this link. For this option, the page runs as a public user for portlets and does not use security for items. Items are displayed, but are only accessible by users who have the appropriate privileges for the items. Portlets only display public content. This option is only available for Standard and Mobile pages.
Don't Cache	Disables page caching. Notes: The use of this option may adversely impact portal performance. Dynamic page generation can affect the performance of your portal by placing a heavy load on both the database and the middle-tier. However, you may want to disable page caching in the following circumstances: Your page contains PL/SQL items or URL items that are rendered in place (i.e., displayed directly on the page) and that produce dynamic content that must always be up-to-date (a portlet that is not cached or that uses a short expiry would be a better choice for this kind of content). You are concerned that a soft-invalidation event, such as a change to user group membership, may result in a cached version of a page being viewed by an active user who has recently lost his privileges on the page.