It would be interesting to have more detailed performance data from the XWiki Java process like a flame graph. We frequently use Glowroot for this purpose on production setups like xwiki.org. One quick idea could be that the query limits introduced in XWIKI-23355 could have an impact. Not so much the limit clauses that might get added in a few queries, but maybe retrieving the configuration value is slow in your setup? You could try specifically for the navigation panel to remove the lines
#else
#validateQueryLimit($limit)
from the content of the page XWiki.DocumentTreeMacros. If the navigation panel expands faster afterwards with XWiki 16.10.11, that could explain it. As the #validateQueryLimit macro is defined in the WAR and added in 16.10.11, this would explain why just downgrading the WAR helps.
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
