|
|
|
|
To maximize your system performance, make sure you've considered the topics detailed below:
Compression (to minimize data transfer volumes)
Database Parameter Tuning (to manage the number of db connections and time out 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 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.
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 occurrence of messages 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.
Warning: 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, you should perform a regular update to the statistics to avoid possible substantially degraded performance.
You may want to periodically review and clean up 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 Maximum Size Allowed for each Attachment (unanet.attachment.max_size) property allows you 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) supply a list of file extensions that are either permitted or prohibited.
As your first step, consider installing the latest supported version of Java. See Required Java Tuning for more information.
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.
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 its own mechanism for database connection pooling and allows you to tune its 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. However, It is 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 effect.
Depending on your operating systems, changes to TCP/IP parameters do not persist through a system reboot. Therefore, you may need to have certain settings 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.
