Hi devs,
@caubin contributed the XWiki Instance Sizing page back in May (XWiki SAS clients keep asking us for sizing information), and @elenicojocariu reworked its structure and prose in a Change Request in August. Note that all the figures currently on the page are unchanged from the original version — the CR reworked the presentation only, so the numbers themselves have never really been challenged.
I asked Claude Code to review the page, and everything below is what it came back with. It’s CC’s analysis, not mine, so treat it as input to a discussion rather than as conclusions — but it did verify the cross-page contradictions and the platform defaults it cites against the actual sources, and those parts hold up. @tmortagne @MichaelHamann your input would be especially valuable on the performance and sizing questions.
The two blocking issues
1. “Page views per second” is defined as HTTP requests per second, and the numbers only make sense for one of the two. The column is labelled Average page views per second, but the definition under the table says “the HTTP requests per second reaching the application server”. One page view is many HTTP requests (skin resources, webjars, REST calls). Working out the implied traffic per user:
| Profile | Active users | pv/s | Implied page views per active user per day |
|---|---|---|---|
| Tiny | 25 | 0.5 | 1,728 |
| Small | 250 | 5 | 1,728 |
| Medium | 2,500 | 25 | 864 |
| Large | 25,000 | 100 | 346 |
1,728 page views per user per day is not a real number, and the page defines “active user” as monthly-active, which makes it worse. The figures look plausible as HTTP requests/s, not as page views/s. Note also that the ratio isn’t monotonic across profiles (1728 / 1728 / 864 / 346), which suggests the three dimensions were each set independently and never cross-checked against each other. As it stands this dimension will never be the binding one for an authenticated intranet, which makes the “keep the highest of the three profiles” rule a no-op for the dimension most directly tied to CPU.
2. The table contradicts our own Performance page, which now links to it. The Performance page still says, under “Memory”: “Small and medium installs: A minimum of 1024MB (-Xmx1024m) / Large installs: 2048MB or beyond” — against the sizing page’s Small 2 GB / Medium 4 GB / Large 8 GB heap. And its “Sizing” section says XWiki SAS cloud instances run on 2 GB RAM, 2 cores and 16 GB disk, which the new page classifies as Tiny. So the two pages link to each other and hand an administrator answers that differ by 2-4x. Which set is right? And whichever it is, the Performance page’s own numbers should then be cut down to a link, since sizing is now owned by the new page.
Content gaps worth discussing
- Version count selects the whole profile, but only affects storage. “Documents, all versions” sits as an interchangeable third dimension, so a 5,000-page wiki with 100 revisions each (500k versions) gets sized as Medium: 8 GB RAM and 4 cores. Revision volume drives DB size and backups, not heap or CPU.
- Storage is the weakest column and its dominant driver is missing. By default we store attachment content and attachment versions on the filesystem (
xwiki.store.attachment.hint=file), and the embedded Solr index in{environment.permanentDirectory}/store/solr, alongside the extension repository, job statuses and recycle bins. So disk splits into the database volume and the permanent directory, the second usually dominates in an attachment-heavy wiki, it can’t be derived from a document count at all, and it’s the one that has to be persisted and backed up. The page has a single “Storage” number and says none of this. - Solr isn’t mentioned once. Embedded vs remote Solr, and the index’s RAM and disk footprint, is one of the main sizing decisions from Medium up — the Performance page already recommends an external Solr for slow searches.
- The Huge row contradicts the page’s own prose. The table is introduced as “a single machine hosting both the XWiki application server and the database server” and includes Huge at 64 GB / 32 GB heap / 24+ cores; the next paragraph says Huge needs a cluster of two or three nodes at 32 GB / 16 GB heap / 16+ cores each plus a dedicated database server. So the single-machine Huge row describes a configuration the page then rules out, and the two specs don’t reconcile.
- The GC justification is dated. The page says a larger heap means longer full GCs that pause the application. On Java 17+/21 with G1 (what supported XWiki versions run on) full GCs are a fallback path rather than the normal reclamation mechanism, and a larger heap directly helps the document and rendering caches. The defensible statement is narrower: don’t take memory away from the OS page cache and the co-located database, and don’t expect heap to fix a CPU- or query-bound wiki. The same sentence lives in the Performance page’s info box, so it’s worth fixing in one place only.
- “Sizing is not tuning” is contradicted two paragraphs later. The intro puts JVM options out of scope and delegates to the Performance page; the main table then has a
JVM heap (-Xmx)column plus a paragraph of GC advice. Keeping heap on the sizing page seems right to me (it’s the number people come for) — then the intro sentence and the Performance page need fixing. - The “Documents” definition isn’t right in XWiki terms. “Documents are the pages, blog posts, attachments and other documents stored in the wiki” — a document is a page, blog posts are pages, and attachments are not documents (they belong to one). The reader is also sent to the Page Index, which gives the current page count, not the “all versions” figure the column actually asks for.
- No provenance and no version. The page will be used for infrastructure purchasing decisions but never says whether the figures are measured, drawn from XWiki SAS operational experience, or estimated, nor which XWiki version they apply to. Given issue 2 above, that matters.
- Smaller ones: say vCPU rather than “cores” (that’s how every cloud offer is quoted); the number of subwikis appears only as “causes variation” in the warning box although each one multiplies Solr cores and caches; backup and snapshot space is unaccounted for; and the co-located-database assumption is worth flagging as unusual from Medium up.
Doc-guide side, minor and separate from the numbers
The Installation topic page doesn’t link the sizing page in its prose (only Prerequisites does), even though it’s a direct child — so it’s reachable only through the automatic “More” table. And lastReviewedDate on the page is still empty.
What I’d like us to settle
- Are the RAM / heap / CPU / storage figures right, and where do they come from? That’s the one question nobody can answer from the page itself.
- Page views/s or HTTP requests/s — pick one and re-derive the column.
- Do we keep the three-independent-dimensions model, or split it so each dimension drives the resource it actually drives (content volume to storage and DB, users and traffic to RAM and CPU)?
- Who owns sizing: the new sizing page, with the Performance page trimmed down to a link — or the other way round?
Thanks
-Vincent