3 Nov
2014
3 Nov
'14
10:23 a.m.
(Sorry for top-posting - I'm stuck with Outlook Live :-(
My system's very small - approx 20 users and very little content at present. It's
for a small collaborative research group which may grew to ~100 members. I expect quite a
few largish attachments and have already configured filesystem attachments.
I'm using PostgreSQL for various reasons, so can't add all the suggested indexes
(names the string prefix ones that are specific to MySQL), but I'd be surprised to be
hitting limits so soon.
The slowdown occurred soon after I opened the wiki to the other members, who probably did
some exploring and perhaps triggered something painful.
________________________________________
From: Paul Libbrecht [paul(a)hoplahup.net]
Sent: 02 November 2014 22:21
To: XWiki Users
Subject: Re: [xwiki-users] Monitoring an Xwiki stack
Btw,
I am not sure you could say the XWiki installs are that "pesky".
However, depending on the user base, it may really need quite some tuning.
For example, if your xwiki manipulates complex documents the document cache may be too big
for the memory, and that you only reach with some time (it could be a week or two).
OutOfMemoryErrors then appear on a regular basis.
Another example has been the amount of registered users. This is a bit too much on curriki
to store into a page of objects, so special treatment has been applied.
Yet another example would be the mass of attachments, e.g if people use this as a shared
disk, where the file-system-attachments solution has helped quite many (I think).
I think all wikis and CMSs that I know of are rather limited in their default goals
(beyond XWiki, I have experience with Drupal and Wordpress) and special treatment maybe be
quickly available, in config, install, or custom development.
Monitoring tools can help you adjust this.
Bryn, maybe you want to indicate how big is your system?
Maybe it's just a matter of some too eager clients (e.g. some ever repeat
javascript-based-requests served to tens of users every second or so)?
paul