Find What Makes a Request Slow
Last modified by superadmin on 2026/10/21 14:27
Content
Steps
XWiki can break a request into its steps and report how long each one took, which is what says whether the answer is a database index, a cache, more heap, or nothing at all: see Performance for what each layer can be made to do.
- Open the slow page with debug=true added to its URL.
https://wiki.example.com/xwiki/bin/view/Space/Page?debug=true - Go to the end of the page, below the footer, where the request's elapsed time tree is rendered.
- Follow the branch that keeps the percentage. Every node shows its own duration and its share of the whole request, and the children of a node account for its time.
- Identify what the dominant step belongs to. A step named Execute Solr query is the search index, Render document and Evaluate content of template are the rendering of the page, and the steps directly under Execute request are what the servlet does before any content is produced.
- The tree now names the layer to act on: one step holds most of the request, with its own duration and its share of the total.
FAQ
Is there anything to switch on first?
No. Debug mode is a URL parameter, so it applies to the request that carries it and leaves nothing running afterwards.
Why does the tree not account for the table or panel that is slow?
Content loaded after the page, such as a Live Data table or an asynchronous macro, is fetched by a request of its own, so its time is not in this tree. The browser's network panel gives that request's duration.
What if the whole wiki is slow rather than one page?
Look in the logs for OutOfMemoryError before reading any tree. Java Memory for Tomcat covers the symptoms and the fix.
