Difference between revisions of "Cache Demo 1"

Latest revision as of 08:28, 28 February 2009

This page demonstrates the use of MediaWiki´s static file caching.

Please watch changes in the content of the next chapter!

Included content (from page Cache Demo 2)

==================================================================
This is page Cache Demo 2.
Change the following letter code to test the caching:     CODE-145
==================================================================

Demonstration

The following links allow you to switch between three different ways to access the current page: {{#vardefine:thispage|Cache_Demo_1}}

First you should click on the third link and then on the first one. Now you are seeing the normal (cached) version of the current page. The cache is up to date, so there is no difference from the other versions. In the first chapter of the current document we have included the content of another page named Cache Demo 2. This is the interesting part of the game. We will watch how (if) the piece of included text changes when we make changes to the underlying page.

The statement we used to include is:

{{#dpl:title=Cache Demo 2|include=*|allowcachedresults=true}}

Make changes to Cache Demo 2 and watch the effect

1. Now open Cache Demo 2 in a separate browser tab and modify the content of that page. We suggest to just increment the letter code at the end of the document.
2. After saving the page switch back to the current page and reload its content, either by pressing your browser´s reload button (e.g. F5) or by clicking on the first of the three above links.
3. When you do this for the first time immediately after you changed Cache Demo 1, you will note that you get the updated content. Why this happens is still somewhat unclear. In that case just make another update to Cache Demo 2.
4. Now you will see that the changes of Cache Demo 2 are not reflected in Cache Demo 1.
5. Now press the second button of the above link list to show the updated page. You will see the most recent content of Cache Demo 2 appear in the first chapter of the current page (Cache Demo 1). This happens due to the fact that special pages are not cached.
6. Switching back to the first button will still show the old cached version of the page. This is also what a third person would see from a different browser client.
7. After pressing the third link button of the list you will see the most recent content AND the cache will be updated. So afterward a click on any of the three above buttons will deliver the same result. An anonymous user pressing the third link will be confronted with a question whether he wants to erase the cache or not. Answer with 'yes'!

Now you can repeat the whole game of editing Cache Demo 2 and watching the effect on Cache Demo 1 until you get the idea. You may also want to show Cache Demo 1 on a second computer with an anonymous user to study the cached view from this perspective.

Try yourself

What is it good for?

If you have a huge wiki with significant traffic you may be afraid that complex parser function calls (like some calls of DPL) will slow down your wiki. In this case you can enable page caching. Then most users will get the version from the cache while you or some privileged users still can access the most recent version.

To activate page caching in your wiki you must

• create a directory $WIKIHOME/cache on your server
• add the following lines to LocalSettings.php:

    $wgFileCacheDirectory = "$IP/cache"; 
    $wgShowIPinHeader     = false;  
    $wgUseFileCache       = true;

This has been done in the current wiki - so the dpldemo wiki runs with page caching enabled.

See also the MediaWiki manual pages.

Note that there is a difference between the manual and the real behaviour you can watch here at this wiki:

• The manual says that the cache only affects anonymous users.
• In reality also a user who is logged in will be served from the cache.

Is there a disadvantage?

This depends on your strategy how to use the cache. As was demonstrated above the caching can lead to a situation where you get an outdated view of a page. But

• this happens only if you want it to happen (for explanation see the next chapter)
• it is easy to provide a mechanism which allows every user to update the cache (again see the example in the next chapter) if he is in doubt about the state of a page shown.
• for pages with purely static content (i.e. the majority of the pages of a wiki) the cache should do no harm - quite in the contrary ;-)

Example with a typical DPL query

Note that DPL by default disables caching to ensure that it always delivers results based on the latest version of all pages. This is a tribute to its name dynamic page lister ...

Therefore DPL must explicitly be told to allow cached results   (using allowcachedresults=true).

Setting this option without enabling MediaWiki page caching does not help very much, however, as DPL still would have to execute SQL statements and process the result. The real performance boost comes when DPL doesn´t have to work at all ...

In the following example we generate a list of all pages starting with "X". We put the time of the generation into the headline so that we can see how the cache works.

generated at Monday, 02:00 -- 2 pages found. Xxx  -  X  -  

For convenience: Offering an automatic refresh link

Version 1.7.7 of DPL gives you an additional option when disabling the cache: If you use allowcachedresults=yes+warn DPL will include a template named Template:DPL Cache Warning into the resultsheader. This is a convenient way to use caching and add a refresh link to the result.

The template tells the user about the cache and offers to reload the page. Here is the example:

90 pages. A1  -  Abc/def  -  A ECP-00055 test page  -  Article with underscore  -  Activity Page 1  -  Activity Page 2  -  A2  -  Aa  -  Annotation URI  -  An article which is only referenced by a DPL query  -  AbC  -  Article connected by DPL category keyword  -  Abc  -  Activity 1  -  Activity 2  -  Activity 3  -  A  -  Apache服务器架设的简单，由小P发布  -  Application DPL-tracker  -  Applying a template to all pages of a given category  -  Allowing true caching by DPL dev page  -  Amethyst  -  Allowing true caching by DPL dev page  -  AssaCom  -  Alf63/C1  -  Alf63/C2  -  Alf63/RP.dpl.default  -  Alf63/SeqSize  -  Alf63/RP  -  Alf63/SeqGet  -  Alf63/RP of  -  Adomjan  -  Arcandio  -  Armin.Egner  -  Alf63/Seq test1  -  Aaron Overton  -  Awodejko  -  Alf63  -  AJim  -  Alf63/P1  -  Anonguy9  -  Arturro  -  Anonguy9  -  Alf63/P1  -  Arrow-closed.png  -  Arrow-open.png  -  Asking a calendar kit 2.png  -  Asking a calendar kit 1.png  -  Amp  -  Ask is a  -  Abc/x123  -  Articles  -  Alias Wgraph  -  African Country  -  Audio  -  ActivitySummary  -  Activity Description  -  About  -  AT&  -  Apachetest  -  AT&T  -  African Union member states  -  Antwerpen  -  Another Topic  -  Allows value  -  Age  -  Annotation URI  -  Architecture  -  Ahnen  -  Add new option to exclude page sections  -  Allow vertical alignment of node labels  -  Assigning absolute position of 0-0  -  Ampersand fails in category names  -  Allow includereplace or ability to ignore included section headers  -  Addlasteditor crashes new article  -  AddContribution missing prefix  -  AddContribution missing prefix regression  -  An Error of conbime using of StringFunctions extension and Simple Form  -  Adduser  -  Add "minimum-number-of-revisions" like Criteria for page selection  -  Article Titles/content added as sub bullets  -  Asking a parser "replace " demo  -  Article count is wrong  -  Add a template in the pages automatically by DPL  -  AiSee crash due to several near edges  -  Allow multiple surrogate templates, add/change syntax  -  Articlecategory doesn't work in 1.6.8  -  A problem in the conbination DPL 1.7.4 and MW1.3 using Chinense interface  -  Arbitrary adding of empty paragraph  -  Asking a calendar kit  -