It was discussed in http://markmail.org/message/bxp5e7snl2yew4f5
With regards to the Navigation Panel: the data for this thing desperately needs to be cached. Having to load from the server every single time you open a page / click an “expand” arrow is infuriating. Cache the data, then load any changes in the background and update the interface. 99% of the time I am looking for a page that I have already seen.
The navigation panel seems to be my biggest problem too. Not only the reload every time you change to another page but also not being able to sort the panel or hide things from it (like blacklisting things).
https://jira.xwiki.org/browse/XWIKI-12895
I think this panel is not intuitive at all and it should give an easy to use navigation panel by default 
4 Likes
Thanks, but you’re describing a possible solution not the problem. I assume that the problem is that the tree is too slow to load / expand? As a simple user I don’t care how the data is loaded or if it is cached. How long does it take to load the tree and to expand a node? How many pages do you have? What version of XWiki and what database are you using? On http://jira.xwiki.org/browse/XWIKI-13700 we did some tests with a few thousands of pages and the request time was decent. See also my last comment there:
I did another test on MySQL with a page that has 100k child pages (half of which are terminal). The mean time (over 20 requests) for expanding this page node and paginating its child nodes is 1.5 seconds. The other nodes in the tree are not affected: expanding the Sandbox page is still ~50ms.
OK, I’ll start again:
AS A USER, I WANT THE NAVIGATION PANEL TO HAVE INSTANT INTERACTIVITY. I do not want to wait for a spinner on every single click of “expand.” I do not want to have to wait for the same spinners every time I navigate to a new page. As for your questions:
It takes 200ms - 1000ms per expand click. Anything less than instantaneous is unacceptable.
Top level: 5 categories. Next level: 7 - 19 categories (which seems immaterial, since you cap the responses at around 15 and slap a “more” label that has to be clicked leading to a spinner.)
Ubuntu 16.04
xwiki-enterprise-common/stable,now 9.4
xwiki-enterprise-mysql-common/stable,now 9.4
xwiki-enterprise-tomcat8-common/stable,now 9.4
xwiki-enterprise-tomcat8-mysql/stable,now 9.4
libmysql-java/xenial,now 5.1.38-1
mysql-client-5.7/xenial-updates,xenial-security,now 5.7.19-0ubuntu0.16.04.1
mysql-client-core-5.7/xenial-updates,xenial-security,now 5.7.19-0ubuntu0.16.04.1
mysql-common/xenial-updates,xenial-security,now 5.7.19-0ubuntu0.16.04.1
mysql-server/xenial-updates,xenial-security,now 5.7.19-0ubuntu0.16.04.1
mysql-server-5.7/xenial-updates,xenial-security,now 5.7.19-0ubuntu0.16.04.1
mysql-server-core-5.7/xenial-updates,xenial-security,now 5.7.19-0ubuntu0.16.04.1
Running on an AWS t2.small instance.
2 Likes
Hi,
First, great work done on xwiki 
Second pain points:
- from developper. Too much .js in xwiki now. It is difficult to debug/customize code. IMO using CSS instead would be better and accessibility friendly. When some js code doesn’t work well, most of features are down.
- from user: too much js with lag (ie spinner.gif) and SpaceIndex macro ’ like missing.
I mean a light tool to displayed all recent children pages of a parent page (with date update decr order)
ie
ty
One of my pain points is with adding users to groups. Ideally, it would be great to edit a user and specify all the groups that they should be a member of. Instead, “editing” a user (admin > users > click user) brings up their “preferences”. It wouldn’t be so bad if Admins had a tab for “Group Membership” here.
Related to this, I have to go through the Groups and add the user to them one at a time. But it’s really annoying that after adding the user to the group, it refreshes the table and goes back to the first page. So now I have extra clicks to get back to the page (when in reality the groups haven’t changed so why refresh?)
@crw I agree that the data should be cached and actually it is already cached. We cache all the documents. Thus it’s not normal that it’s slow for you. Maybe you have a lot of docs and you have a too small document cache? Look in the performance page for how to configure this. Except for this we’d also like to introduce a title cache which would allow us to not have to load documents at all and should increase perf even further, especially for the cases when some docs are not in the cache. The downside would be that there would be some cases when the displayed title is not fully up to date but that should not happen often and is IMO an acceptable trade off.
Hi Vincent, thanks for your reply! I am talking specifically about the Navigation Panel. It looks like a nested tree view of the page titles of the wiki.
The loading spinners that show up on that thing are super-annoying, especially because it is a highly-trafficked widget, at least in my use case.
With regards to caching, I specifically meant caching in the browser; either in localStorage or IndexedDB. Basically, cache the tree structure so you don’t have to keep making user-visible JSON calls. It would be better to show old data and then fill in updates in the background even if it mutates the UI while I am looking at it. The current “wait every time for tree level n to load every time you click the expand arrow” is driving me crazy.
Yes, I understood that. My reply was in that context, i.e. the document titles are extracted from documents that are loaded in the XWiki document cache. Now that I’m online I can point you to the doc for the document cache, in case you have lots of docs: http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Performances#HDocumentCache
If you want fast operations you need to have a large enough doc cache so that all frequently used docs find themselves in the cache.
Yes that could be an extra layer of optimization. But we’d still need the title cache if we want to go beyond the doc cache.
Normally the tree should open in under tens of milliseconds (ie almost instantaneously). I’ve just tried it on http://playground.xwiki.org and I get instantaneous results. Maybe the connection from your browser to your server is slow?
I agree, the behavior on playground is usable, although still not perfect. To be honest, if it didn’t show the spinner when the load time is < 100ms or something, it would probably “feel” more seamless.
It is possible there is additional latency going to my AWS instance for some reason. According to the Page Index, there are 239 pages total in the wiki. From my xwiki.cfg:
#-# Maximum number of documents to keep in the cache.
#-# The default is 500.
# xwiki.store.cache.capacity=500
Is there a way to tell if the server cache is saturated? I know very little about Java. I will say, on a reboot, XWiki takes several minutes to start up, and only after the first attempt at a page view. I assumed that was XWiki caching stuff. Not sure if this is helpful, but a quick peak at free memory:
$ cat /proc/meminfo
MemTotal: 2046536 kB
MemFree: 134408 kB
MemAvailable: 868540 kB
Buffers: 262932 kB
Cached: 444620 kB
SwapCached: 0 kB
Should I start a new topic for this conversation? It seems like there are two threads: one, can the Navigation Panel be made to be more robust; two, is there a degenerate case with re: performance on AWS t2.small instances.
I agree, it would be better to start two new threads on that. Thanks!
On my xwiki I displayed users group in user profil with this piece of code in XWiki.XWikiUserProfileSheet (with xwiki editor):
<dd #if("$!vCardProperty" != '' && !$inEditMode)class="$vCardProperty"#{end}>$doc.display($sectionProperty)</dd>
#end
#end
</dl>
#end
#end
</div>
</div>
#if (!$inEditMode)
<div class='half column'>
#if (!$isGuest)
<div class='userMessage profile-section'>
<h1>Groupes</h1>
## * $xwiki.getUserName($doc.fullName, false)
## * $doc.fullName
#set($rightsAPI=$xwiki.rightsmanager)
#set($groupsAPI=$rightsAPI.getGroupsApi())
#set($groups=$groupsAPI.getAllLocalGroupsNames())
#set($user=$doc.fullName)
#foreach($group in $groups)
## * [[$group]]
##set($user=$doc.fullName)
#if($xwiki.getUser($user).isUserInGroup($group))
##* $xwiki.getUserName($user)
* [[$group]]
#end
#end
</div>
#end
<div class='userRecentChanges'>
#if ($xcontext.user == $doc.fullName)
<h1>$services.localization.render('platform.core.profile.section.activity')</h1>
#else
<h1>$services.localization.render('platform.core.profile.section.activityof', [$xwiki.getUserName($doc.fullName, false)])</h1>
1 Like
Another point: a user space missing. I mean a space where the xwiki user could create his personal pages (like homedir on Linux.)
Maybe the profile of user could be a parent page (and not a terminale page anymore)?