Page Comparison

...

Architecture and Overview

Caching occurs in the front-end frontend server processes and has links with JSP rendering [D] and the time stamps table [E], As you can see in the image below. A page request [A] from a website visitor goes through some filters [B] and arrives at the caching module [C].

...

The caching module first determines whether a cached file exists of for the page request. If the file exists, go to [A], otherwise go to [B]

1. [A] Retrieve the timestamp of the page (or SSI) by performing a query on the Timestamp database. The database is not always queried but instead the timestamps are also cached in the caching module. The timestamp is compared with the date of the file in the cache. If the timestamp is newer then the file is returned [D], otherwise the page has to be rendered.
2. [B] The page must be regenerated. Therefore , therefore a request goes from the caching module to the backend servlet in order to render the page. This takes some time and it’s the slowest scenario. After the page has been rendered, it is stored as a file in the cache directory [C] and the page is returned.

...

In a very basic setting the caching module can save local cache files based on every page request , for example every URL. But in several cases this may not really speed up the page rendering because parts of the page might change often. Dynamic Content Overviews are an example of page sections parts that can change often.

In XperienCentral, page sections parts can be cached. This happens with is done using Server Side Includes (SSIs). This is a common mechanism where whereby tags are placed inside the (HTML/JSP) source code. These SSI tags refer to other pieces of code and can be referenced by local file path or URL. When the application server encounters an SSI tag it will request the SSI and add the generator code to the page. The following is an example of an SSI tag:

...

Polls are elements that can change quite often when a lot of people vote. Therefore , therefore it is better to use an SSI for the Poll Element. In a basic situation where you add a poll element to a page, the page.jsp is used as a starting point. The page.jsp will require the /pagepart/content.jspf, which will call the /element/pollElement.jspf. Before we look into this .jspf let’s examine the /element/pollElement.xml file:

...

To see the SSI in action on a page you have to perform the following steps:

1. First make sure you can login log in to your application server as an administrator. For Tomcat this involves editing the file /conf/tomcat-users.xml in the Tomcat directory. Example:
   
   

   Code Block
   theme Eclipse
   <?xml version='1.0' encoding='utf-8'?> <tomcat-users> <role rolename="wmadmin"/> <user username="wmadmin" password="123456" roles="wmadmin"/> </tomcat-users>

   
   
   

2. Restart Tomcat and go to the URL http://<hostname>:<port>/web/admin. Enter the username and password.
3. Create a page in XperienCentral and add a Poll element. Enter some information in the poll element and publish the page.
4. Open the page on the backend hostname: open a new tab/window in your browser and go to  http://<hostname>:<port>/web/show. This will show the homepage of your website without using the cache. Navigate to the page with the poll element.

5. Add the following string to the URL of the page: /ssidebug=true and refresh the page. This should show the string we have seen in the previous paragraph, something like:
   
   
   

   Code Block
   theme Eclipse
   <!--#include virtual="/web/show?id=26111&langid=43&cachetimeout=120&elementHolder=26114&ssiObjectClassName=nl.gx.webmanager.cms.element.PollElement&ssiObjectId=72418"-->

   
   It’s possible to paste the marked part after your backend hostname and port number and open it in a browser. You will then see the code of the poll element and nothing else. This exercise shows that individual SSIs can be rendered on their own by passing the right parameters (such as elementHolder and ssiObjectClassName to a /web/show command.

...

1. To enable caching go to frontend_system_settings  section of the General tab of Setup Tool - and ensure that the allow_cache checkbox is selected.
2. You can test if it works by requesting several pages on the front-endfrontend. Verify if whether there are subdirectories with numbers created in the cache directory (the default is /work/cache for local installations and /cache for production servers).
3. If you want to make sure that most pages are generated (and therefore in the cache) before a website goes live you can run the XperienCentral search engine. 

...