Xwiki performance

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Xwiki performance

Daniel Johansson
We have been using xwiki (currently 2.2) for an intranet application for some time. Everyone really likes it so far except for one big gripe; performance. It seems if you haven't accessed the wiki in a while it can take upwards of 30 seconds before the page is rendered. Subsequent access is faster, a couple/few seconds lag before page is rendered. This is still not what we would expect on an intranet network.
We are running it on MS server 2008. Xwiki is configured as an app in the same container as our code collaborator installation (which is always very fast as expected). The server load is low, never more than a few users at the same time.

Any suggestion would be appreciated; I'm not very familiar with java servlet stuff.
Reply | Threaded
Open this post in threaded view
|

Re: Xwiki performance

Daniel Johansson
It appears that the OfficeImporter was not properly configured and caused the stall at the start if a new session? Disabling this function seems to eliminate the 30+ seconds occasional stalls. Still the responsiveness overall is not that great. Typically ~2-3 seconds for each page to render.
Reply | Threaded
Open this post in threaded view
|

Re: Xwiki performance

Daniel Johansson
Ok, that wasn't the issue either. We're at loss, this is a real drag. Random stalls of almost 30 seconds. And overall delayed rendering. Any suggestions on how to move forward?
Reply | Threaded
Open this post in threaded view
|

Re: Xwiki performance

rmacd
I've got exactly the same issue. It's fine if the users are on and it's just been used. But rendering from having not visited the site can take upwards of 20-30s by which time users think it's just broken so move on.

It's a fantastic application but unfortunately it's difficult to tune right.

I've so far tried the following:

XWiki/Tomcat
XWiki/Tomcat/nginx
XWiki/Tomcat+APR/nginx
XWiki/Jetty
XWiki/Jetty/nginx

There was for sure a noticeable difference between using Tomcat and Jetty - Jetty is very much more snappy.

However, even with altering the available memory (now at 300M) and changing cache values in xwiki.properties, offloading the static content to nginx etc etc - it's still impossible to get rid of this lag. Looking at process output displays Java consuming a large proportion of the available CPU cycles.

I've also noticed a fair bit of data being written to the logs. Having set a log4j.properties within the xwiki context to cool down on the logging, there's still a lot of data (mainly SQL transaction-related) happening.

One theory was that of the database's configuration - but to be honest, doubts ensue as XWiki is not the only DB client running on the system so therefore if I was seeing any lag at all in XWiki I'd also have been seeing them on the DB. I'd followed the instructions so as to create the necessary indexes though this still does nothing to help after a server restart or first-access.

Therefore I'm pretty stuck as to what exactly is going on. I'm failing to pinpoint the bottleneck.

-Ronald.


--EDIT--

Additionally I have applied many of the options (with a pinch of salt) available on http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Performances. Though the improvement is noticeable, I'm still having problems with the large 'start-up' time and the lag that Daniel explains re browsing from page to page.
ronald macdonald
ronald@rmacd.com
http://www.rmacd.com
Reply | Threaded
Open this post in threaded view
|

Re: Xwiki performance

Daniel Johansson
I switched back to Jetty, cache back to 100, disabled backlinks. I don't see the 20-30 s stalls anymore, more like 2-4 seconds. Still pretty weak considering intranet and gigabit lan.
Reply | Threaded
Open this post in threaded view
|

Re: Xwiki performance

rmacd
Ah right yes I'd seen that in the xwiki.cfg but thought it was quite useful. However I'm willing to scrap that in favour of getting a sharper response.
ronald macdonald
ronald@rmacd.com
http://www.rmacd.com