Performance Parameters
Last modified by Eleni Cojocariu on 2026/10/21 15:51
Content
Reference
Each parameter below buys speed or memory by giving something up. They are read at startup, so a change takes effect on the next restart. All of them ship commented out at the default shown except xwiki.backlinks, which the shipped xwiki.cfg leaves active at 1. In xwiki.cfg, 1 means true and 0 means false.
In xwiki/WEB-INF/xwiki.cfg
| Parameter | Default | What it does | What is given up |
|---|---|---|---|
| xwiki.store.cache | 1 | Keeps documents in memory in front of the store. | Every page read goes to the database. Switch it off only when memory is critical. |
| xwiki.store.cache.capacity | 500 | How many documents that cache holds. | Below the number of documents a wiki actually serves, reads fall through to the database; above it, the extra entries only cost memory. |
| xwiki.store.cache.pageexistcapacity | 10000 | How many entries the cache of "does this document exist" holds. | Little: the entries are booleans, so this cache can be large without costing much memory. |
| xwiki.backlinks | 1 | Records, on every save, which pages link to which. | The list of pages linking to a page, everywhere it is used. Saving a document costs noticeably less without it, loading one slightly less. |
| xwiki.monitor | 1 | Collects per-request statistics through the Monitor plugin. | The statistics themselves. The calls are spread through the code, so switching it off saves a little memory and a great many method calls. |
| xwiki.monitor.lastlistsize | 20 | How many recent requests the Monitor plugin remembers. | Depth of history in those statistics. |
| xwiki.store.hibernate.custommapping | 1 | Allows an XClass to be stored in a table of its own instead of the generic schema. | The faster queries custom mapping gives a wiki holding large numbers of objects of one class. See Custom Mapping. |
In xwiki/WEB-INF/xwiki.properties
| Parameter | Default | What it does | What is given up |
|---|---|---|---|
| url.useResourceLastModificationDate | true | Adds a resource's last modification date to the URL XWiki generates for it, so a browser fetches the new file as soon as it changes. | Browsers keep serving the cached copy of a skin or WebJar file after an upgrade until it is force-reloaded. Switching it off saves a file-system check per resource, which is measurable only on slow or unusual storage. |
Tuned elsewhere
Four more switches belong to this list by their effect but are documented where the feature is:
- Document and attachment versioning, and the recycle bins, in Optional Store Features.
- Statistics storage, in Statistics Parameters.
- The rendering cache, in Cache the Output of Slow Pages.
- Options belonging to an extension, with that extension. Synchronising large LDAP groups in particular is tuned through the LDAP Authenticator's own configuration.
FAQ
Which of these is worth changing first?
None of them, until a measurement points at one. Find What Makes a Request Slow says which layer holds the time.
Does switching off the Monitor plugin remove the elapsed time tree?
No. That tree is produced by XWiki's progress API, not by the Monitor plugin, and debug=true keeps working either way.
