| Status: | effective |
| Progress: | 75% |
| Version: | 2.5.0+ |
| Found errors or typos? Just edit the page or leave a message on the talk page. The English language documentation is canonical and most up to date. |
Cache (or caching) is specified as an storage mechanism were earlier computed values are stored separately from the original request and hereby enable future requests to be served faster using the already computed results.
The general suggestions (where feasible) is to use redis1234 as cache backend to ensure that large blob objects can be stored and retrieved without impacting the general performance.
Technical aspects[edit]
The PageUpdater controls three caches:
- HtmlCache
- WebCache (eg. Squid)
- ParserCache
Preliminary notes[edit]
- CachedPropertyValuesPrefetcher.php
- PropertySpecificationLookup.php makes use of the
CachedPropertyValuesPrefetcher
Configuration settings[edit]
Caching (either temporary or persistent) is an important part of MediaWiki's storage strategy and also became an infrastructural component in recent Semantic MediaWiki releases to ensure that editing and viewing experience is improved. It further helps to reduce the amount of computational tasks performed required by Semantic MediaWiki.
An expensive (and memory intensive) task is MediaWiki's Parser::parse with responsibility to turn wikitext into a HTML representation. It also includes processing (or signalling) extension to add or modify data before the output process is finalized.
- Configuration parameter
$wgParserCacheType(MediaWiki.org) − Sets how to keep parsed pages in a cache to speed up output of the same page viewed by another user with the same options - Configuration parameter
$smwgMainCacheTypeSets which object cache Semantic MediaWiki should use to track temporary changes (see also configuration parameter$smwgCacheTypeSets which object cache Semantic MediaWiki should use to track temporary changes) - Configuration parameter
$smwgValueLookupCacheTypeSets a separate cache type for the object cache when requesting value lookups from the database in conjunction with configuration parameter$smwgValueLookupCacheLifetimeSets the cache lifetime of the value lookup cache until it is being invalidated - Configuration parameter
$smwgQueryResultCacheTypeSets whether the query result cache may be used in conjunction with configuration parameter$smwgQueryResultCacheLifetimeSets the cache lifetime of embedded queries and their results fetched from the query engine- Cache eviction is triggered by:
- end of lifetime (handled by cache provider)
- query dependency changed (handled by configuration parameter
$smwgEnabledQueryDependencyLinksStoreSets whether tracking and storing of dependencies of embedded queries may be used if enabled) or - manual by user (configuration parameter
$smwgQueryResultCacheRefreshOnPurgeSets whether it is possible to manually refresh the query cache by doing a "purge" action)
- Cache eviction is triggered by:
- Related
- Configuration parameter
$smwgFactboxUseCacheSets whether or not a factbox content should be stored in cache. - Configuration parameter
$smwgFactboxCacheRefreshOnPurgeSets whether or not a cached factbox should be invalidated on an action=purge event.
See also[edit]
Note[edit]
Please be aware that this page is being used as reference in MediaWiki:Smw-sp-properties-cache-info.
References
- ^ Why Redis beats Memcached for caching "... Memcached and Redis serve as in-memory, key-value data stores ... Redis gives you much greater flexibility regarding the objects you can cache. While Memcached limits key names to 250 bytes and works with plain strings only, Redis allows key names and values to be as large as 512MB ..."
- ^ How fast is Redis?
- ^ Clarifications about Redis and Memcached
- ^ The issue with APCu is that it will store its cache in the PHP shared memory and means that different PHP processes share the available memory. See also Additional notes for Redis vs. APCu on Memory Caching
