Application server tuning parameters

 

+
Search Tips   |   Advanced Search

 

Each application server instance contains interrelated components, called a queuing network, that must be properly tuned to support the specific needs of your e-business application. The queuing network helps the system achieve maximum throughput and maintain the overall stability of the system.

You can tune the following application server settings:

• Object Request Broker
• Dynamic cache service
• Web container
• EJB container
• Session management
• Data sources
• Process Priority

 

Object Request Broker

An Object Request Broker (ORB) uses the Internet InterORB Protocol (IIOP) to manage the interaction between clients and servers. It supports client requests and responses received from servers in a network-distributed environment. Object Request Broker tuning guidelines provides tips on using these parameters to tune the ORB. You can tune the following ORB parameters:

• Pass-by-reference (com.ibm.CORBA.iiop.noLocalCopies)

  • For remote method calls, this parameter specifies that the ORB passes parameters by reference instead of by value. If pass-by-reference is disabled, the ORB copies parameters to the stack before every remote method call is made.

  • How to view and set:

    1. Go to...

       administrative console | Servers | Application Servers | application_server | ORB Service

    2. On the ORB Service page, select the Pass by reference check box.

    3. Click Apply or OK.

    4. Save the configuration.

    5. Stop and restart the application server.

  • Default value: Disabled

  • Recommended value: Enabling pass-by-reference can enhance performance, but is not specification compliant. Some applications may not run correctly if you enable pass-by-reference.

    Enterprise bean local interfaces can provide many of the performance benefits of pass-by-reference in a specification compliant manner.

• Connection cache maximum (com.ibm.CORBA.MaxOpenConnections)

  • This parameter specifies the largest number of connections allowed to occupy the service's connection cache.

  • How to view and set:

    1. Go to...

       administrative console | Servers | Application Servers | application_server | ORB Service

    2. On the ORB Service page, specify a value in the Connection cache maximum field.

    3. Click Apply or OK.

    4. Save the configuration.

    5. Stop and restart the application server.

  • Default value: 240

  • Recommended value: Adjust this value as necessary to support the number of clients that connect to the server-side ORB. You can increase this value to support up to 1000 clients.

• Thread pool Maximum size

  • This value specifies the maximum number of threads in the pool. Each call to an EJB method from a separate JVM (either on the same system or another system) uses an ORB thread. If your application calls EJB methods only from servlets in the same JVM, you probably do not need to tune this parameter.

  • How to view and set:

    1. Go to...

       administrative console | Servers | Application Servers | application_server | ORB Service

    2. On the ORB Service page, click Thread Pool.

    3. Specify a value for the Maximum size field.

    4. Click Apply or OK.

    5. Save the configuration.

    6. Stop and restart the application server.

  • Default value: 50

  • Recommended value: Increase this value if the Percent Maxed metric in Tivoli Performance Viewer is consistently greater than 10.

• com.ibm.CORBA.ServerSocketQueueDepth

  This is a custom property for the ORB Service.

• com.ibm.CORBA.FragmentSize

  This is a custom property for the ORB Service.

You can also tune several custom paramters

 

Dynamic cache service

Dynamic caching maintains server-generated content in memory for servlets, JavaServer Pages (JSP) files, commands, and web services. Items that are called frequently with identical parameters are good candidates for dynamic caching. Dynamic caching is ideal for Web sites that use mass personalization or have a very high number of calls to a particular set of servlets or JSP files. Because the application does not have to generate the output every time a servlet or JSP file is called, the dynamic cache service can improve performance.

 

Web container

Each application server includes a Web container. The application server routes servlet requests along a transport queue between the Web server plug-in and the Web container. Default Web container properties are set for simple Web applications. However, these values might not be appropriate for more complex Web applications. You can adjust these parameters to tune the Web container based on the specific needs of your environment:

• Thread pool Maximum size

  • Limits the number of requests that your application server can process concurrently.

    The information on the settings page applies to all thread pools in WebSphere Application Server.

  • To set:

    1. Go to...

       administrative console | Servers | Application Servers | application_server | Web Container | Thread Pool

    2. Specify a value for the Maximum size field.

    3. Click Apply or OK.

    4. Save the configuration.

    5. Stop and restart the application server.

  • Default value: 50

  • Recommended value: Set to handle the peak load on your application server. Specify a maximum size less than or equal to the number of threads processing requests in your HTTP server. A value in the range 25-50 is generally a good starting point. Use the Tivoli Performance Viewer to monitor the number of threads being used.

• Growable thread pool

  • Specifies whether the number of threads can increase beyond the maximum size configured for the thread pool.

  • How to view or set:

    1. Start the administrative console.

    2. In the topology tree, expand Servers and click Application Servers.

    3. Click the name of the application server that you want to configure.

    4. Click Web Container.

    5. On the Web Container page, click Thread Pool.

    6. Select Allow thread allocation beyond maximum thread size.

    7. Click Apply or OK.

    8. Save the configuration.

    9. Stop and restart the application server.

  • Default value: Disabled

  • Recommended value: Do not enable this property if you are confident the Thread pool Maximum size is large enough to adequately process the peak load on your application server. Set to true if you want the thread pool to be able to exceed the configured maximum pool size. This setting is beneficial in the event that the application server receives an unexpected increase in requests or the maximum pool size is set too low. In this scenario, additional threads are created to handle the increased number of requests. These connections are destroyed when the number of requests returns to its typical level. However, enabling the growable thread pool setting might cause a large number of threads to be created, and have a negative impact on system storage and performance.

  You can also tune several custom parameters for HTTP transports in the Web container.

 

EJB container

Each application server includes an EJB container. Use the following parameters to make adjustments that improve performance:

• Cleanup interval

  • This parameter specifies the interval at which the container attempts to remove unused items from the cache. The cache manager tries to maintain some unallocated entries that can be allocated as needed. A background thread attempts to free some entries while maintaining some unallocated entries. If the thread runs while the application server is idle, the application server does not need to remove entries from the cache before it can allocate new cache entries.

  • How to view or set:

    1. Start the administrative console.

    2. In the topology tree, expand Servers and click Application Servers.

    3. Click the name of the application server that you want to configure.

    4. Click EJB Container.

    5. On the EJB Container page, click EJB Cache Settings.

    6. Specify a value for the Cleanup interval field.

    7. Click Apply or OK.

    8. Save the configuration.

    9. Stop and restart the application server.

  • Default value: 3000

  • Recommended value: Increase the value of parameter as the cache size increases.

• Cache size

  • This parameter specifies the number of buckets in the cache. A bucket can contain more than one active enterprise bean instance, but performance is maximized if each bucket in the table has a minimum number of instances assigned to it. When the number of active instances within the container exceeds the cache size, the container periodically attempts to passivate some of the active instances. For more information, see EJB cache settings.

  • How to view or set:

    1. Start the administrative console.

    2. In the topology tree, expand Servers and click Application Servers.

    3. Click the name of the application server that you want to configure.

    4. Click EJB Container.

    5. On the EJB Container page, click EJB Cache Settings.

    6. Specify a value for the Cache Size field.

    7. Click Apply or OK.

    8. Save the configuration.

    9. Stop and restart the application server.

  • Default value: 2053

  • Recommended value: For the best balance of performance and memory, set this value to the maximum number of active instances expected during a typical workload. To estimate the number of active instances, multiply the number of entity beans active in any given transaction by the total number of concurrent transactions expected. Then add the number of active session bean instances. User the Tivoli Performance Viewer to monitor this setting.

For more information about tuning enterprise bean performance, see these topics:

• Assemble EJB modules
  During application assembly, you can break Container Managed Persistence enterprise beans into several enterprise bean modules.

• Enterprise bean method invocation queuing

• Access intent policies

 

Session management

The installed default settings for session management are configured for optimal performance.

See also:

• Tune session management
• Tuning parameter settings

 

Data sources

Applications uses data sources to access databases. The following data source settings can affect performance:

• Connection pooling

  • Maximum connection pool

    • This value specifies the maximum number of managed connections for a pool.

    • How to view or set:

      1. Go to...

         Start the administrative console | Resources | JDBC Providers | provider_name | Data Sources | data_source | Connection Pool

      2. Specify a value in the Max Connections field.

      3. Click Apply or OK.

      4. Save the configuration.

      5. Stop and restart the application server.

    • Default value: 10

    • Recommended value: Set the value for the connection pool lower than the value for the Max Connections option in the Web container. If the pool is larger than necessary, it might waste memory and other system resources. A setting of 10-25 is suitable for many applications. For additional about connection pool size, see Queuing network. Use Tivoli Performance Viewer monitor connections. When the application reaches a stable state, look for connections that are being closed instead of returned to the pool.

  • Minimum connection pool

    • This value specifies the minimum number of managed connections for a pool.

    • How to view or set:

      1. Go to...

         Start the administrative console | Resources | JDBC Providers | provider_name | Data Sources | data_source | Connection Pool

      2. Specify a value in the Min Connections field.

      3. Click Apply or OK.

      4. Save the configuration.

      5. Stop and restart the application server.

    • Default value: 1

    • Recommended value: Set the minimum pool size to handle the average load on the system. Use Tivoli Performance Viewer to monitor the pool.

• Statement cache size

  • WebSphere Application Server provides a statement cache for each data source. This value represents the number of free prepared statements per connection in the connection pool. The statement cache stores query information for the data source. You can adjust to size of the statement cache to optimize performance.

  • How to view or set:

    1. Go to...

       Start the administrative console | Resources | JDBC Providers | provider_name | Data Sources | data_source

    2. Specify a value in the Statement Cache Size field.

    3. Click Apply or OK.

    4. Save the configuration.

    5. Stop and restart the application server.

  • Default value: 10

  • Recommended value: In most situations, it is recommended that you set this to the number of unique statements for each application that uses the datasource. Setting the cache size to this value avoids cache discards, and generally results in the best performance. However, if the cache is too large, it might cause performance problems as a result of increased cache management and increased use of system resources. If you have a large number of unique statements, a smaller number might be appropriate. Use Tivoli Performance Viewer to monitor the cache size.

 

Process Priority

• The priority setting establishes the Application Server job's run priority. The default process priority is 25. The application server does not override the default behavior of Java thread creation. Worker threads within the server are configured to run at 6 levels lower than the job's run priority. Therefore, by default, the priority of the worker threads is 31.

• How to view or set:

  1. Go to...

     administrative console | Servers | Application servers | application_server | Process Definition | Process Execution

  2. On the Process Execution page, specify a value in the Process Priority field.

  3. Click Apply or OK.

  4. Save the configuration.

  5. Stop and restart the application server.

• Default value: 25

• Recommended value: In most situations, the default value is acceptable. However, if other workloads are running at a higher priority (that is, with a lower priority number), you might need to adjust the application server's priority so that it can more easily access the necessary resources.