To maximize your system performance, make sure you've considered the topics detailed below:
Compression (to minimize data transfer volumes)
Database Parameter Tuning (manage the number of db connections and timeout values)
Update Database Statistics (this routine DB maintenance item is particularly important after a migration)
SQL Server - Maintain SQL Server Transaction Log file sizes (keep log file sizes under control)
File Attachment Type and Size (keep attachment file sizes under control)
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)
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.
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 |
unatime.database.maxconnections
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.
unatime.database.idletimeout
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.
unatime.database.activetimeout
This parameter specifies the amount of time a connection can remain active in the pool before being flagged as long running.
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.
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.
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.
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.
If you are using JRun4
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.
If you are using Tomcat
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.
If you are using WebLogic
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.
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.
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.
This information is included for your convenience only. Please refer to the Apache Tomcat site for detailed platform configuration and tuning recommendations.
Remove unused connectors. If you are using an external Web server with Tomcat and do not use Tomcat in a stand-alone mode, you may want to remove the HTTP Connector for stand-alone operation. The HTTP Connector entry can be found in the server.xml file.
Enable thread pooling for the remaining connectors.
Configure the pooling parameters.
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) |
This information is included for your convenience only. Please refer to the Oracle (BEA WebLogic) site for detailed platform configuration and tuning recommendations.
Do not enable WebLogic's JDBC connection pooling as Unanet application has it's own mechanism for database connection pooling and allows you to tune it's parameters (see Unanet parameters).
Configure the thread count for the execute queue used by Unanet application.
A default WebLogic installation satisfies the needs of all applications by using a single default execute queue. It is however possible to configure additional execute queues and assign applications to specific queues. Regardless of which execute queue you are using for the Unanet application, the default one or the one created specifically for Unanet, you will need to alter the thread count for that queue.
Parameter |
Default |
Recommended |
Description |
ThreadCount |
15 |
30 |
The number of threads in the pool |
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.
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:
Tuning kernel parameters:
Maximum number of Threads per process
Maximum number of File Descriptors per process
Maximum number of Threads system wide
Maximum number of File Descriptors system wide
Tuning TCP/IP parameters:
Maximum Pending TCP Connections
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.
This information is included for your convenience only. Please refer to the Microsoft site for detailed platform configuration and tuning recommendations.
Set Windows machine as an application server.
If using IIS take the following steps:
Set IIS performance for 100,000+ hits per day
Put IIS log on a disk other than the Unanet application
The following items may be considered if you'd like to increase your platform capacity:
Add additional processors per server
Increase memory on servers
Add additional web server platforms (sharing a single database server).
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.