All Versions
Fisheye 4.2 DocumentationFisheye 4.1 Documentation
Fisheye 4.0 Documentation
More...
This page contains information about improving FishEye's performance.
On this page:
FishEye is now multi-threaded, allowing you to control the number of threads dedicated to the repository indexing process. See the page on Configuring Indexing.
The heap size of the FishEye Java Virtual Machine is controlled by the FISHEYE_OPTS environment variable. The best heap size to use is dependent on a number of factors including:
FishEye will reserve a portion of the available heap for caching of database data. So in general, the more memory you can supply, the better.
For Subversion repositories, it is also possible to reduce FishEye's memory footprint by reducing the BlockSize parameter.
If you do run into 'Out of Memory' errors, you will need to increase the heap size and restart FishEye. In this situation, try increasing your FISHEYE_OPTS variable to 512MB. Setting FISHEYE_OPTS is similar to the instructions for setting JAVA_HOME.
You can follow the same procedures, only using FISHEYE_OPTS in the 'Variable name' field, and using the following 'Variable value':
-Xmx512m
(this requires a reboot under Windows)
To do the same thing under the Linux console, you can type the following:
export FISHEYE_OPTS=-Xmx512m
This would need to be set to run on boot, or set in your FishEye startup script, if you have one.
For more information, read the detailed instructions on setting environment variables.
When you add a repository, FishEye needs to perform a once-off scan through the repository to build up its initial index and cache. This scan can take some time. Until this scan is complete, you may find that some data is not displayed. As a guide, FishEye should be able to process about 100KB-200KB per second on an averaged-size PC. If FishEye is accessing the repository over the network (e.g. over a NFS mount), then you should expect the initial scan to take longer.
You can increase the speed of your scans using the following options:
One option is break large repositories into multiple smaller repositories. While this technique will not improve the overall initial scan time, it allows for all fully scanned repositories to be updated while the initial scan is still being performed on those remaining.
In FishEye 1.3.4 and later, the initial and incremental scans happen in separate, single threads. So, splitting the repositories will allow incremental scans to run concurrently alongside the initial scans. You may also wish to split projects into separate repositories, since permissions in FishEye are applied on a per-repository basis.
The http/s protocol has the slowest performance during the initial scan. The svn protocol (svn://) is faster and the file protocol (file:///) is the fastest.
Therefore if you find your initial scan takes an extended amount of time (in some cases weeks), you should consider switching over from the http/s protocol to the svn or file protocol to define the location of your SVN repository.
E.g. Switch from https://example.com/svn/project/ to svn://example.com/svn/project/ or file:///home/user/some/location/svn/project
In order for SVN protocol to work you need to have set up an svnserve based server.
If your svn repository is located on a different server than where your fisheye is installed and thus you do not have file access to the repository, you may wish to consider mirroring the svn repository onto the server where fisheye is installed. To do this, you can use rsync (even though the instructions are for CVS, rsync can be used to mirror SVN as well).
If you have implemented at least one of the suggestions above but are still experiencing slow performance, ask us for help: