We have a fisheye instance which indexes 2 bigger svn-repositories. After some bigger changes in svn (which produced several thousand changesets which each did just change the content of a pom.xml) we noticed a very bad performance. It needed about a week to update the index.

When analysing the problem I came to the suspicion that there is a no parallelizing/MP-Support and some synchronization issues.

I attached three graphs from our monitoring system:

Memory:
Memory: Fisheye has a maxMem of 3.5GB - only 3 GB are used on the system so memory is not the problem

CPU:
The box has 2 cpu. The graph is showing a utilization of near 50% (one CPU is in use and the other is idleing). Most is used on user-space - there is no real IOWait (so the network or svn itself is not the problem)

ContextSwitches:
There is a really big amount of ContextSwitches which leads me to the conclusion that there are synchronization issues in the code

As a workaround we moved the fisheye instance onto the subversion server and are now using the file-protocol. This sppeds up the indexing to a subjective normal value. As currently said subversion itself is not the problem (we would hav IOWait issues) so I assume that the problem (or at least the trigger) should be around the http-access to svn

I would suggest to analyze the code an do some optimization at this point.
Additionally I would suggest to improve the multiprocessing-support at this point.