This is version . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]
TitleClicking on 'more info' on http://www.jspwiki.org/wiki/Main takes a very long time
Date24-Sep-2005 01:28:46 EEST
Version
SubmitterKeesKuip
Bug criticalityLightBug
Browser version
Bug statusNewBug
PageProvider used
Servlet Container
Operating System
URLhttp://www.jspwiki.org/PageInfo.jsp?page=Main
Java version

Clicking on 'more info' on http://www.jspwiki.org/wiki/Main takes a very long time.

I would like to profile what the problem is and maybe then fix it. Therefore I need the complete wiki-data-directory of the site http://www.jspwiki.org/ Is there a way to get this? Or could some one create a tgz/zip file?

-- KeesKuip

Ok. Here's a snapshot of the latest file. http://www.ecyrd.com/~jalkanen/JSPWiki/snapshot.tgz. I will also put it on JSPWikiSnapshot.


OK, here are the first results. (I already posted yesterday but I thought my measurements were wrong so I removed them late at night).

Here's how I test:

  • undeploy JSPWiki
  • deploy war
  • start profiler (which starts tomcat)
  • call page Main
  • start profiling the cpu.
  • call page 'More info' of Main-page
  • stop profiling (measurement 1)
  • call page Main
  • start profiling the cpu.
  • call page 'More info' of Main-page
  • stop profiling (measurement 2)
  • .. and the same way for (measurement 3)

I measure 262883/263008/269400 msec. (measurement 1/2/3) for jspwiki v2.2.33.

I notice a hotspot in FileUtil.java.copyContents(). I changed the method so that it would read more than 1 byte/char at one time and write more than 1 byte/char at one time. This resulted in a measurement of 53657/34565/35238 msec.

The result is an improvement in speed of 5-7 times the orginal. Not bad for a first run!. I attached the new FileUtil.java (It is backward compatible).

-- KeesKuip


More results.

In the snapshot after the fileutils-patch I noticed a hotspot in loading property files. When I call page 'More Info' of the page 'Main' I see that there are 2419 invocations to properties.load(). That must be wrong!

So I debugged it a little bit and saw that very often the propertyfile is asked that had just been asked before. So I decided to cache only (in a safe way) the last loaded propertyfile in VersioningFileProvider.java(info). That resulted in 150 invocations to properties.load(). Much less, but I smell bad programming here.

The measurements are:
before: 53657/34565/35238 msec (see previous post)
after: 19417/19251/18634 msec.
An improvement of almost 2x.

So patch 1 and 2 together give an improvement in cpu-time of about 13x. (Mind you: This patch does give a 2x improvement but calling load-properties 150x for 1 page just smells like something is wrong in the design.)

This patch is downward compatible.

More to come.

-- KeesKuip.


The next culprit was the PageSizeTag. It calculates the pagesize in a very cpu-intensive manner. The pagesize is then initialized in wikipage.setSize() so the next time it is known immediately.

A wikipage is loaded with the "PageManager" that lets a "FileProvider" implements its "getPageInfo()" method. This getPageInfo() returns a WikiPage. So why not set the size of the WikiPage in that method? I did it for VersioningFileProvider and got the following measurements:
before: 19417/19251/18634 msec. (see previous post)
after: 9330/8021/7890 msec.
An improvement of more than 2x.

So all patches together give an improvement in cpu-time of more than 30x.

This patch is downward compatible. The patch is also done in VersioningFileProvider.java(info). So the attached file combines patch 2 and 3.

-- KeesKuip


Oef, A major setback!

I changed the FileUtils.copyContents() (see patch1) twice. One for an InputStream and once for a Reader. The changes were both perfectly allowed and good. But there is a reader TranslatorReader which has not implemented its contract as a Reader good. The results are that with the changes in patch1 I get empty pages. So for now I've reversed the change in copyContents of the Reader.

The performance improvement of patch1 will now be 4x ! I measure 66529 msec.

I've already patched TranslaterReader, but it will not perform any better. The problem is this: The CheckVersionTag wants to now if a page exists with a certain versionnumber. So it only want's to know if a page exists but then the complete page is read in memory and translated. This is just bad! The pageExists takes 56222 msec of the total of 66529 msec!!!!

Just look at the profile for this problem: profile.png

-- KeesKuip


Kees, don't worry. The 2.3 translator works far better with respects to your first issue. Don't worry about it too much. The latter is a problem, I admit. It is easily fixed by making the call to pageExists() use the pageExists( page.getName() ) instead of just page - this way any existence of the page is checked.

-- JanneJalkanen

OK, your right! If I check if the pageExists(page.getName()) AND verify that the version number is smaller then we can be pretty sure that pageExists(page.getName(), version) exists.

I think The performance gain would then be back to 30x. Which would be nice because the frontpage gets defaced quite often and it takes a long time to de-deface it.

-- KeesKuip.

Add new attachment

Only authorized users are allowed to upload new attachments.

List of attachments

Kind Attachment Name Size Version Date Modified Author Change note
java
FileUtil.java 8.7 kB 3 02-Oct-2005 12:53 KeesKuip
patch
VersioningFilePageExistPatch.p... 3.4 kB 1 15-Oct-2005 18:03 KeesKuip
java
VersioningFileProvider.java 20.1 kB 2 02-Oct-2005 12:38 KeesKuip
patch
VersioningFileProvider.patch 1.4 kB 1 05-Oct-2005 19:16 KeesKuip
java
WikiEngine.java 62.7 kB 1 04-Oct-2005 19:58 KeesKuip
patch
WikiEngine.patch 0.3 kB 1 05-Oct-2005 19:16 KeesKuip
png
profile.png 84.7 kB 1 02-Oct-2005 14:20 KeesKuip
« This particular version was published on 04-Oct-2005 01:00 by KeesKuip.