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 running the system with compression enabled (which it is by default).  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 disable HTML compression, you would need to uncheck the Enable gzip  (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 Maximum Size Allowed for each Attachment  (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 File Extensions that are Not Allowed  (unanet.attachment.invalid_file_extensions) and File Extensions that are Allowed  (unanet.attachment.valid_file_extensions) can be used to supply a list of file extensions that are either permitted or prohibited.


Java Tuning

As your first step, consider installing the latest supported version of java.   See Required Java Tuning for more information.


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.


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.