XWiki Instance Sizing
Reference
An XWiki deployment is sized by matching its usage to a named instance profile, then provisioning the hardware listed for that profile. Sizing is not tuning: JVM options, caching, database indexes and clustering are covered by the Performance page.
Instance Profiles
A profile is determined by three independent dimensions. Evaluate each one and keep the highest of the three profiles.
| Profile | Typical deployment | Active users | Documents, all versions | Average page views per second |
|---|---|---|---|---|
| Tiny | Personal wiki, proof of concept, small team intranet | Up to 25 | Up to 5,000 | Up to 0.5 |
| Small | Departmental wiki, small company intranet | Up to 250 | Up to 100,000 | Up to 5 |
| Medium | Company-wide wiki, collaborative portal | Up to 2,500 | Up to 1,000,000 | Up to 25 |
| Large | Enterprise-wide wiki, public-facing knowledge base | Up to 25,000 | Up to 10,000,000 | Up to 100 |
| Huge | Multi-tenant farm, high-traffic public wiki | More than 25,000 | More than 10,000,000 | More than 100 |
- Active users are the accounts that log in and interact with XWiki at least once a month. Readers browsing public pages without authenticating count as page views instead.
- Documents are the pages, blog posts, attachments and other documents stored in the wiki. The "Index" tab of the Page Index gives their current number; including their versions takes a query on the database.
- Average page views per second are the HTTP requests per second reaching the application server over a representative day, read from the reverse proxy logs or from an APM tool.
An instance with 800 active users (Medium), 60,000 documents (Small) and 8 page views per second (Medium) is therefore sized as a Medium instance.
Sizing Recommendations
The values below are for a single machine hosting both the XWiki application server and the database server. The JVM heap is a subset of that RAM, set explicitly rather than derived from it; the remainder is shared by the operating system, the database engine and the memory the JVM uses outside its heap.
| Profile | RAM | JVM heap (-Xmx) | CPU | Storage |
|---|---|---|---|---|
| Tiny | 2 GB | 1 GB | 2 cores | 5 GB |
| Small | 4 GB | 2 GB | 2 cores | 20 GB |
| Medium | 8 GB | 4 GB | 4 cores | 100 GB |
| Large | 16 GB | 8 GB | 8 cores | 500 GB |
| Huge | 64 GB | 32 GB | 24+ cores | 1 TB+ |
Do not give the JVM more heap than the profile calls for: a larger heap holds more objects at any time, and the full garbage collections that reclaim them pause the application for longer. An instance running on HSQLDB is the exception, since it keeps the whole database in the heap.
At the Huge scale the architecture is planned against the actual workload and monitored continuously. Such an instance also needs:
- a cluster of two or three application nodes and a dedicated database server, each application node sized at 32 GB of RAM, 16 GB of JVM heap and 16+ cores;
- a dedicated reverse proxy, with static-asset caching and HTTP compression enabled.
FAQ
Should I size for future growth?
When an instance is close to the upper boundary of its profile, provision the next profile up, so that growth does not force a disruptive infrastructure change later.
Where is the JVM heap set?
In the startup configuration of the servlet container: for Tomcat, see Java Memory for Tomcat.
