Performance Tuning Tips

To maximize your system performance, make sure you've considered the topics detailed below:

Unanet Parameter Tuning

 

Java Tuning (check your java version and tune memory pool allocation sizes)

Servlet Engine Tuning (thread count tuning is essential)

 

Operating System Tuning (a number of kernel parameters can improve performance)

 

Expand Platform Capacity

 


Unanet Parameter Tuning

Compression

To improve the application response time, especially for users on slower connections, we recommend enabling compression.  The idea is to compress data being sent out from the server hosting the Unanet application, and have the user's browser decompress this data on the fly, thus reducing the amount of data sent.  A compressed page loads faster onto the screen, especially over slower connections.  

Unanet uses the GZIP encoding method to compress pages (html, java script, etc).  

If you encounter problems, you may want to verify that browsers used by people in your company support "content-encoding" (most modern browsers support content-encoding).

To enable HTML compression, you'll need to enable the unanet.gzip property.   


Database Parameter Tuning

To change these parameters, you need to access the database.properties file located in the config directory of your Unanet installation.  Change the values, save the file and re-start your servlet engine.

Parameter

Default

Description

unatime.database.maxconnections

16

Maximum database connections per Unanet installation

unatime.database.idletimeout

600000 milliseconds (10 minutes)

Time period after which an idle connection will be dropped

unatime.database.activetimeout

28800000 milliseconds (8 hours)

Time period after which an active connection will be flagged as long running

 

This parameter limits the number of database connections established by the Unanet application at any one time.  The Unanet application pools database connections and allows connection reuse.  The same connection may be used by multiple users.  Thus, the number of database connections does not equate to the number of concurrent users.

 The default setting for this parameter should be sufficient for a typical Unanet installation.  However, if you experience performance problems you should check your servlet engine logs.  If you find a message that resembles the following:

Adding connection (15 in pool)

it may indicate that the number of connections is insufficient for your installation.  You should look for the occurrences of message(s) that resemble the following:

Dropping idle connection (15 in pool)

Dropping idle connection (14 in pool)

...

Dropping idle connection (0 in pool)

The above messages indicate that the connections are being released.  If you do not find these messages, it means that all the connections continue to be used.  In that case you should probably increase the value of this parameter.  

A word of caution,  as you increase the value of this parameter, you should monitor the impact a higher number of connections has on your system -- as a higher number of connections equates to a higher number of statements executed concurrently.  If set too high this can have an adverse affect on your overall performance.

This parameter limits the amount of time an idle connection will be kept alive in the pool.  The default setting for this parameter should be sufficient for a typical Unanet installation.  

If you decide to modify this parameter, please consider the following: you would not want to set this parameter too low since there is an overhead associated with establishing a connection.  At the same time, a number of system resources are necessary to support a connection.  Minimal as those resources are, a large number of idle connections kept around for a significant amount of time will have an impact on the overall system performance.

This parameter specifies the amount of time a connection can remain active in the pool before being flagged as long running.  


Update Database Statistics

Make sure that your database optimizer has the best possible information for query optimization by executing any necessary routine maintenance procedures.  For example, with the Oracle database, you should make sure that your standard maintenance includes updating the database statistics periodically.  This is particularly important after a version migration, in which case many tables and indexes may have been dropped and recreated, invalidating any previously collected statistics.  In high volume systems, not performing a regular update to the statistics has been known to result in substantially degraded performance.


SQL Server  - Maintain SQL Server Transaction Log file sizes

You may want to periodically review and cleanup any large transaction logs and otherwise check that you have adequate disk and memory space for continued smooth database operation.

See Microsoft support articles for tips regarding managing database transaction log size.


File Attachment Type and Size

Database sizing needs can be challenging to predict, particularly with respect to the various file attachment features within Unanet (e.g. expense report, project note and project note comment attachments).  To help control attachment size and allowable types, the following properties can be used.

The unanet.attachment.max_size property allows for the ability to specify a maximum allowable size for an attachment.  The default value is approximately 10 MB.  The unanet.attachment.invalid_file_extensions and unanet.attachment.valid_file_extensions can be used to supply a list of file extensions that are either permitted or prohibited.


Java Tuning

Depending on your servlet engine's compatibility with the Java 2 platform, it would be best to upgrade your system to the latest available version of the Java 2 SDK.  The newer versions of Java typically contain a number of performance improvements over previous versions.  

When using the Client JVM (typically the default), note that it is optimized for applications that run for shorter time periods between restarts.  This JVM is typically faster for applications that are restarted on a regular basis (ie several times per month).

 

Parameter

Default

Recommended

Description

mx

16 M

128 M

Maximum size of the memory allocation pool for a JAVA virtual machine.

ms

1 M

32 M

Start up size of the memory allocation pool for a JAVA virtual machine

** Note that how you set these parameters will be somewhat dependent on the physical memory you have installed on your server.  If you have adequate memory available on the server you may want to consider a higher maximum (e.g. 256, 512, etc).

*WebLogic recommends 512M as both min and max settings.

The recommended values are sufficient for a typical Unanet installation.  However, should you receive the java.lang.OutOfMemoryError message after the recommended settings were applied, you will need to further increase the maximum size of the Java memory allocation pool.

To change these parameters, you need to change the JAVA virtual machine parameters used when your servlet engine starts.

Add the following text (in red) to the jvm.config file for the default server located in <JRun home>/bin:

java.args=-Xmx128M -Xms32M -Dunanet.properties=c:\\unanet\\unanet.config

Please note that the java.args line should already exist and should specify the location of the Unanet.properties directory.  

The same can be accomplished through the GUI interface by accessing  default > settings > JVM Settings and adding the following text before the unanet.properties definition:

-Xms32M

Now make sure the Max Heap Size setting is 128 MB (or a value appropriate for your platform).  Restart JRun default server for the change to take effect.

Set the following environment variable:

     CATALINA_OPTS="-Xmx128M -Xms32M"

Restart Tomcat for the change to take effect.

Depending on your Tomcat versions / setup, you may need to use the Tomcat Configuration Tool to make this change.  Also note that where / how you make these changes depend on which version of Tomcat you are running.

For example, when using the tool you may need to place the -Xmx128M and -Xms32M parameters in the  Initial Memory Pool & Maximum Memory Pool fields if they exist, otherwise you may need to append the entire string -Xmx128M -Xms32M into the java options field.

For example, to launch the Tomcat tool, right click on the system tray icon and select configure...:

A screen resembling the following will be displayed.

Once displayed, click on the Java tab, to manipulate the Initial Memory Pool and Maximum Memory Pool values.

Additional Java parameters can be specified at startup time.  The command to start the WebLogic Server can be either typed in a command shell manually or it can be placed in a script to avoid retyping the command each time the server is started.  In either case, it will probably look similar to the following:

"%JAVA_HOME%\bin\java" -hotspot -ms512m -mx512m -classpath "%CLASSPATH%" -Dweblogic.Domain=mydomain -Dweblogic.Name=myname "-Dbea.home=f:\bea" weblogic.Server

If you are using a startWebLogic script provided by BEA, you can modify the start command to include Java parameters.  If you are using a Windows platform and have WebLogic installed as a service, you will need to re-install the service with the additional Java parameters.


Servlet Engine Tuning

The information in this section is compiled based on the recommendations made by each product's vendor.  For further details please refer to their online documentation.

Servlet Engine Restarts:  As a best practice to ensure maximum performance, you might consider scheduling a periodic restart of your servlet engine.  The frequency of such a restart would depend on your system usage.  If you routinely update your servers with the latest OS / virus patches, etc. you may already have a system restart schedule in place.


JRun Parameter Tuning

The parameter tuning for this product line has changed a bit each version.  Check out the Adobe Site for up to date information about tuning JRun.

If your application handles high request volume, you may want to consider modifying the ActiveHandlerThreads and MaxHandlerThreads settings for the JRunProxyService (in the jrun.xml configuration file).

Parameter

Default

Recommended

Description

activeHandlerThreads

25

20 - 100

Maximum number of web threads that are actively running.

maxHandlerThreads

1000

300 - 3000**

Maximum number of web threads queued + running.

minHandlerThreads

1

1

Minimum number of web threads to have around at all times.

 

** Note that the Recommended values may vary based on your hardware (e.g. # of CPUs) and operating system.  For example, regarding the maxHandlerThreads, the recommendations may be 300 - 500 for Linux systems, 1000 - 2000 for Solaris systems and up to 3000 for Windows systems.  You should refer to your vendor specific help documentation for more information regarding the tuning of these products.


Tomcat Parameter Tuning

This information is included for your convenience only.  Please refer to the Apache Tomcat site for detailed platform configuration and tuning recommendations.


Parameter

Default

Recommended

Description

max_threads

50

100

The maximum number of threads in the pool

max_spare_threads

25

25

The maximum number of idle threads in the pool

Does not apply to Tomcat 7 (results in warning message)

min_spare_threads

10

10

At least this number of idle threads in the pool

Does not apply to Tomcat 7 (results in warning message)



WebLogic Parameter Tuning

This information is included for your convenience only.  Please refer to the Oracle (BEA WebLogic)  site for detailed platform configuration and tuning recommendations.


Parameter

Default

Recommended

Description

ThreadCount

15

30

The number of threads in the pool

 


Operating System Tuning

The information in this section is compiled based on the recommendations made by each product's vendor.  For further details please refer to their online documentation.

 

General Unix / Linux Parameter Tuning

This information is included for your convenience only.  Please refer to your operating system specific vendor site for detailed platform configuration and tuning recommendations.

There are a number of kernel and TCP/IP parameters that you may want to investigate tuning depending on the size of your user community and the equipment you are running on.  The names and number of these parameters vary from OS to OS, but in general, you may be interested in the following:

 

 

Please note that if these parameters are changed while the Unanet application is running, the new settings will not take effect.  The application needs to be restarted after the new settings are applied.   Kernel parameter adjustments will likely require a system reboot in order to take affect.

Depending on your operating systems, changes to TCP/IP parameters do not persist through a system reboot.  Therefore, you may need to have certain setting added to your system startup scripts.  Refer to your vendor specific documentation for additional information.


General Windows Parameter Tuning

This information is included for your convenience only.  Please refer to the Microsoft site for detailed platform configuration and tuning recommendations.


Expand Platform Capacity

The following items may be considered if you'd like to increase your platform capacity:

 

Multi-Web Server Considerations:

Note that if you proceed with a multi-front end configuration, you will need to take care to keep both front ends up to date regarding Unanet versions (including having them on the same point release) and you'll want to make sure your property file settings are consistent across the front end servers as well.  

Additionally, you may need to keep the server clocks synchronized.

Finally, when considering a load balancing solution for multi-front ends, you'll want to be sure to utilize a 'sticky' option, that is, take measures to ensure that when a user is serviced by a particular server, they stick with that server.  This is necessary for certain features in the system, for example, when you attempt to export a file, the temporary file is created on a particular server and thus you'll want to make sure that the user's subsequent request to download that file is serviced by the same front-end server.