Performance
Explanation
A wiki is rarely slow everywhere at once. The time a request takes is spent in a few distinct places, and each of them has its own levers, so the first move is to find out which one holds the time: Find What Makes a Request Slow breaks a request down step by step, and the step it points at decides which of the pages below applies.
Hardware and the JVM heap
An instance short of memory is slow everywhere and eventually stops with an OutOfMemoryError. How much RAM, heap and CPU an instance needs follows from its size rather than from tuning: XWiki Instance Sizing gives the figures per profile and explains why a larger heap is not automatically better, and Java Memory for Tomcat is where they are set.
The database
XWiki creates the indexes declared in its Hibernate mappings and no others, so a few queries scan whole tables once a wiki grows. The indexes worth adding are listed per database in Optional MySQL Indexes and Optional Oracle Indexes. When the symptoms look like corrupt data rather than slow queries, Check the Database for Inconsistencies looks for rows XWiki cannot have written. An application storing a great deal of data in one XClass can also be given a table of its own instead of XWiki's generic schema, which is a developer task described in Custom Mapping.
Search
XWiki embeds its own Solr instance, which keeps a new wiki to a single process. When searches are slow while the rest of the wiki is not, moving to a standalone Solr server is the answer; the Solr Search API module documents how.
Page rendering
A page that aggregates outside data or runs slow queries pays that cost on every view. Cache the Output of Slow Pages caches whole pages for a chosen duration, the Cache Macro caches one fragment of a page, and the LESS Module documents the cache that keeps skin stylesheets from being recompiled on every request.
Static resources and the browser
Skins, scripts, stylesheets and WebJars change rarely, and the browser can be told to keep them: Compress and Cache Static Resources, configured on the reverse proxy in front of the wiki.
Crawlers
Search robots visit every URL a public wiki exposes, including the expensive ones. Block Crawlers From Expensive URLs keeps them to the pages that are worth indexing.
Features that cost what they give
Versioning, backlinks, statistics and the document cache each trade work at save or load time for a feature. Performance Parameters lists the switches and what is lost by changing each one; versioning and the recycle bins are in Optional Store Features, and statistics in Statistics Parameters.
Users and content structure
Two things change as a wiki grows rather than as it is configured. An instance with thousands of accounts should stop materialising the membership of the "all users" group: Support Thousands of Users. And a navigation tree is expanded one node at a time, so what costs is the number of children a single node has, not the number of pages in the wiki: content nested in pages stays fast where thousands of siblings under one parent do not, most sharply on HSQLDB.
More than one instance
When a single instance is correctly sized and still saturated, or when the wiki has to survive a node going down, Clustering is the next step.
FAQ
Will adding a second node make the wiki faster?
No. A cluster spreads load across nodes, so a page that is slow to render is equally slow on every one of them.
Is there a single setting that makes XWiki faster?
No. Each switch trades a feature for a little speed, and none of them compensates for an undersized instance or a missing database index.
More
To find more about the current topic, you can search or use the table below and filter the columns to narrow your choices.
