Vincent Massol wrote:
On Jan 4, 2009, at 9:53 PM, Elek Márton wrote:
Can you start by verifying if the problem is in your database, in your web server (if you have any) or in XWiki? I tried it in two different machine with two different configuration (tomcat + myql and the simple XWiki distribution with jetty + embedded db) but the results were the same, so I think the problem is in the XWiki. (I am planning to profile it with VisualVM or NetBeans.)
The News page at XWiki.org is also rendered a little slowly for me (http://www.xwiki.org/xwiki/bin/view/Main/News?category=&nbstart=4 is retrieved between 5 and 7 seconds).
For xwiki.org the page is cached and it would be normal since it's remote so you need to add up network times.
Is this a large wiki? Sure. We are trying to migrate a snipsnap based wiki (http://jhacks.anzix.net) to XWiki. We have about 500 blog posts and also a lot of wiki pages.
Ok so that's probably the reason then. We must have some bugs in the old blog post (intensive queries) that are only visible when there are lots of blog posts.
Fortunately we've fully rewritten it from scratch and improved it a lot. We're almost ready to release it. Do you think you could try it: http://maven.xwiki.org/snapshots/com/xpn/xwiki/platform/applications/xwiki-a...
Since this is quite long, a short summary first: 1. The old blog app is buggy, in Blog.WebHome #includeMacros should be replaced with #includeTopic. 2. With several thousands articles, most of the time is spent in searchDocuments (just this one call takes more than 90% of the time). 3. Still, the query is not that complex, and with 2000 documents * 2000 objects a serious database should not have any problems. 4. The new blog application is slightly slower than the old one (if the bug in point 1 is fixed) as an acceptable cost for the new published feature. I just ran some tests on the old and new blog applications, with the following results: - The old blog application had a bug which caused all the articles to be displayed in a discarded buffer. The problem is that Blog.WebHome uses #includeMacros to include the Blog.Macros page (which behaves more like a sheet than a macro container document). The current rendering engine pre-parses all the documents included with #includeMacros, and for the initial parsing the $nbstart and $nbitems variables are not defined, so #blog($category $nbitems $nbstart) will actually process all the blog entries (but in a discarded buffer, so nothing gets printed to the user). For the second run, when the result is actually printed, the correct values are used for $nbitems and $nbstart, so only 10 items are displayed. A quick fix is to replace #includeMacros with #includeTopic, which works just fine. After fixing this bug, some performance numbers: - With 1000 documents it takes about 0.4 seconds to display the blog homepage in both applications. - With 2000 documents, it takes about 1.5 seconds to display the blog homepage in the old application, and a bit more (but still under 2 seconds) in the new application. Most of this time is spent in the getDocuments call (1.3 seconds), due to the large number of entities that have to be joined (2000+ XWikiDoc * 2000+ BaseObject * many thousands properties). This time was achieved on a laptop (2.26GHz dual core) with the default jetty + hsqldb distribution. - The new blog takes more to run the search query because it also has to join with the 'published' and 'hidden' properties, which is a new feature of the new application. The performance penalty is not that big, so this is IMHO an acceptable cost. - I didn't run a performance test on Glassfish+Derby or on Tomcat+mySQL, but I think that with the right indexes in place it will be a lot better. 2000 documents is not that much for a serious database, but it seems to be quite a lot for hsql. -- Sergiu Dumitriu http://purl.org/net/sergiu/