Cache Page Manager
Allows management of cached pages.
The LumisXP allows optimization of access to pages through the HTML Cache feature. When a page is configured to use HTML Cache, its access is managed by generating a static file with the corresponding content.
Every static HTML Cache file is cached by Page Generators distributed on the servers as per configuration. Each generator has a set of threads determined by its generation profile configuration.
The cached files are organized in queues, allowing the configuration of independent generators for sets of pages. The generation queues define the caching strategy for your pages, for example, whether generation is on-demand only, and whether HTML files should be removed when the cache is cleared.
WebResource Cache Resolution
When executing a page, LumisXP analyzes its HTML looking for URLs for pages configured with HTML Cache. For each URL found, a WebResource is generated. When creating a WebResource, the properties of the pages are read to determine their behavior. At this moment, the WebResource queue is calculated.
The behavior of the WebResource is generated only when it is created. If LumisXP finds the WebResource already persisted, it will be reused and its properties will not be regenerated. Thus, the properties of the page that may have been updated will not be automatically reflected in the WebResource's behavior.
The properties are configured through the definition of Property Bags:
- lumis.portal.page.cache.IPageCacheQueueResolver: Defines the Java class used to determine the id of the queue in use. If this property is not configured, the queue's id will be the id defined in the lumis.portal.page.cache.queueId property.
- lumis.portal.page.cache.queueId: Defines the default queue id to be used. If this property is not configured, the value used will be: default.
The Lumis allows optimization of access to pages through the HTML cache feature.
When a page is configured to use the HTML cache, LumisXP manages its access by generating an HTML file with the corresponding content for each URL. If the URL has parameters, for example, in a page that wishes to display the details of a specific news item, LumisXP generates an HTML file for each set of recognized parameters.
Pages that have user interaction interfaces, whose parameters are not known by the portal, can only be cached if these interfaces are configured as client-side. This is because interfaces that have render actions, just like other POST request, do not normally work in HTML cache, as it only takes into account query strings and not parameters in POST.
When the interface is configured for client-side rendering, it works correctly on a page with HTML caching enabled, as the render actions are rendered dynamically, without utilizing the HTML cache infrastructure. Such interfaces include: filters with values entered by the user, participating in the Chat Room service, login (using the standard product interface style), among others. The exception is for the Search service since parameters are passed via query string, and therefore, an HTML cache will be generated for each query.
Interfaces that execute process actions cannot be cached.
There is a limitation regarding pages that contain add and edit interfaces, belonging to services like Forum, Wiki, and Blog, for example. They cannot have the HTML cache enabled. Due to their dynamic nature, it is not beneficial to enable HTML caching for pages of these services.
The page HTML cache is optional and must be determined in the general properties of each one, in the portal administration.
Pages that are not cached (dynamic pages) will always be displayed as: /main.jsp?lumPageId= XXXXX.
On the other hand, the page cache (static page) is displayed with the ".HTM" extension. In addition, the file name is a Guid. For example: http://domain:port/context/data/pages/8A488A1D22BD37260122BD51809F0652.htm. The htm page is generated in www/data/page.
It is important to note that the extension is configurable and with friendly URLs the Guid will be adapted.
The URL is that defined in the <frameworkUrl> element of the <htmlGeneration> configuration located in the file lumisdata/config/lumisportalconfig.xml:
This file also contains other configurations that can be made for the desired functioning of page caching. Below are the details of these configurations:
- connectTimeout: Number of milliseconds for the cache generator connection timeout, by default 30000;
- pageRequestTimeout: waiting time in milliseconds for the generation of an HTML page;
- frameworkURL: Allows you to define the URL that the cache generator uses to display the HTML pages. When not defined in this parameter, or if the <htmlGeneration> configuration is commented out, the value of the <frameworkURL> parameter located at the beginning of the lumisPortalConfig.xml file will be assumed;
- htmlCacheLogNavigation: When enabled (value "1"), monitoring information of the page view event is also collected for pages with HTML caching;
- htmlFileExtension: determines which extension will be used for the generated pages. By default, it is .HTM;
- shtmlFileExtension: determines which extension will be used for the generated pages when using the SSI technology. By default, it is .shtml;
- sendRedirectOnPageNotFound: configuration for cache with SSI. If configured as "true" (default value), it allows that when the cache with SSI is accessed, but has not yet been generated, it performs a sendRedirect for the browser to reaccess the htm page after it has been generated. This parameter is necessary, for example, in scenarios where some application servers use caching features. Thus, even if the htm page exists, the result may be as not found, and only after a few seconds the application server's cache is updated;
- waitBeforeSendRedirect: configuration for cache with SSI. It allows configuring the waiting time in milliseconds to perform a sendRedirect for the browser to reaccess the HTM page after it has been generated. The default value is 500 milliseconds. This parameter is necessary, for example, in the same scenario described above. It would be the time in milliseconds needed to perform the next sendRedirect, in the interval used by the application server to update its cache.
- expirationLimit: configuration to define the maximum allowed number of webresources that can be expired in a single data rendering change event. If the number of involved webresource exceeds the defined limit the expiration process will not occur and a log will be generated indicating the problem. The default value for the expirationLimit option is 0 and indicates that there is no restriction on the number of webresources that can be involved in a single data expiration event. The cache cleaning operations provided in Portal Studio are not subject to the previously mentioned restriction. Similarly, other operations may decide not to use the limit set through the API during the emission of the event. The configuration is used if another limit is not forced by the implementation that generates the event.
See also
Permissions
- Manage service instance: Allows managing all data of this service instance, including deleting it entirely.
- Edit content of service instance: Allows managing all data of this service instance with publisher profile.
- View service instance: Allows viewing public data of this service instance.