Optimising the performance
The default settings of the Delft-FEWS program are tuned for forecasting systems. These systems generally do not have a huge amount of data and table records. However, historical databases might have millions of table records, which may slow down the performance at the user interface and also the forecasting shell servers.
It is possible to change the default memory settings and to increase the performance. The settings below can be used for the OC, the FSS and stand alone systems.
Before 2014.02, configurating the *.jpif files
The user interface is started by using a jpif file, that contains the JAVA settings. This file looks like:
..\jre -mx512m -cp $JARS_PATH$ nl.wldelft.fews.gui.explorer.Application WIS_Dommel_OC
The second line contains the definition for the maximum allocated memory, in this case 512 MB. This value can simply be changed to allow for more allocated memory.
Since 2014.02, configurating the *.ini files
#Delft-FEWS ini file main.class=nl.wldelft.fews.gui.explorer.Application classpath.1=*.jar #Java Runtime jvm.dll location vm.location=../jre/bin/client/jvm.dll vmarg.1=-Xms512m vmarg.2=-Xmx1024m
The flag -Xmx specifies the maximum memory allocation, while -Xms specifies the initial (and minimum) memory allocation. The value for -Xmx is the most significant value of the two, the value for -Xms has some influence on the startup time of the application. We recommend to set it to the same value as the value for -Xmx. The choice of -Xmx should be balanced. A too small -Xmx memory setting has a lower memory footprint on an Operating System with limited memory, but may cause OutOfMemoryErrors to appear. When rolling out a Delft-FEWS application, it is best practice is to test the application with a low memory setting first (e.g. 512M), perform some performance tests with intensive viewing of grids first. If while using a low -Xmx setting, the application's performance becomes sluggish, it is likely that the Java garbage collection memory management process is responsible. In that case it is time to tune to a higher -Xmx setting. When running on Windows 32 bits and the -Xmx value is set too high for 32 bits (>1500M), it reduces the available memory for native drivers (e.g. firebird) and the Operator Client / ConfigManager may suffer from lack of native memory. For testing a configuration, 512M is a good starting point, but 1024M is the most commonly used value for end-users running 32-bits. For 64-bits mode, higher numbers can be used if necessary. The final roll out of the Delft-FEWS application should be able to run smoothly with the specified -Xmx value.
Verifying amount of memory configured via the About Box
To analyse the currently used amount of memory in the user interface, you can open the About box from the Help menu. There you see the next window:
In this case the allocated memory for the map is already huge. Therefore it might be useful to increase the allocated memory in the ini-file (before 2014.02 jpif).
Changes to global.properties
To increase the performance of handling time series (e.g. in graphs or spatial display) you can increase the default allocated memory for caching time series.
Therefore you should add the next line to the global.properties.
timeSeriesDefaultCacheSizeMB=100
In this example 100 MB is allocated. The default value is 10 MB.
You can also increase the allocated memory for time series that are created during task runs (at a forecasting shell). To do so you should add the next line to the global.properties.
timeSeriesTaskRunCacheSizeMB=100
In this example 100 MB is allocated. The default value is 30 MB.
Temporary time series (synchLevel 9) are written to the database when the size of the write cache is not large enough to hold them in memory. This will cause a lot of extra work for the rolling barrel later on. You can set the size of this cache in the global.properties.
timeSeriesWriteCacheSizeMB=100
In this example 100 MB is allocated. The default value is 10 MB.
