Tune parameter index

 

Overview

Each WAS process has several parameters influencing application performance. One can use the WAS administrative console to configure and tune applications, Web containers, EJB containers, appservers and nodes in the administrative domain.

It is recommended that you first review the Tuning parameter hot list, which is a subset of the tuning parameter index. These parameters have an important impact on performance. Because these parameters are application dependent, the parameter settings for specific applications and environments can vary.

Each parameter in the tuning parameter index links to information that explains the parameter, provides reasons to adjust the parameter, how to view or set the parameter, as well as default and recommended values.

  1. Application servers
  2. Java Virtual Machines
  3. Applications
  4. Databases
  5. Java messaging service
  6. Security
  7. Hardware capacity and settings
  8. Operating systems
  9. Web servers

 

Application servers

By tuning appserver settings, you can control how an application server provides services for running applications and their components. WAS contains interrelated components that must be harmoniously tuned to support the custom needs of your end-to-end e-business application. This group of interrelated components is known as the queuing network. The queuing network helps the system achieve maximum throughput while maintaining the overall stability of the system.

One can tune the following appserver settings:

  1. Object Request Broker
  2. XML parser definitions
  3. Dynamic cache service
  4. Web container
  5. EJB container
  6. Session management
  7. Data sources

 

Java Virtual Machines

The appserver, being a Java process, requires a Java Virtual Machine to run, and to support the Java applications running on it. As part of configuring an application server, you can fine-tune settings that enhance system use of the JVM. In addition to the following tuning parameters, see also Java memory tuning tips.

Use the following JVM parameters, including garbage collection options for IBM Developer Kit 1.3.1, to tune the Java Virtual Machine.

  • Generic JVM arguments

  • Initial heap size

  • Maximum heap size

  • Disable just in time (JIT) compiler

  • Garbage collection policy

    • Specifies if the garbage collection policy (gcpolicy) is set to optavgpause so that concurrent marking is used to track application threads starting from the stack before the heap becomes full. The garbage collector pauses become uniform and long pauses are not apparent. The trade-off is reduced throughput because threads might have to do extra work.

    • To set:

      1. Click through:

        Console | Servers | Application Servers | server_name | Additional Properties | Process Definition | Java Virtual Machine

      2. Enter a value...

        -Xgcpolicy:[optthruput|optavgpause]

        ...in the Generic JVM Arguments field.

      3. Click Apply or OK.

      Default: optthruput
      Recommended: optthruput

  • Sun JDK 1.3 Generational Garbage Collection

    The Sun JDK 1.3 introduces generation garbage collection, which makes use of separate memory pools to contain objects of different ages. GC cycle collects these objects independently from one another. Additional parameters allows to individually set the size of these pools. To achieve better performance, set size of pool containing short lived objects sufficient enough, so that objects in the pool do not live through more then one garbage collection cycle. Size of new generation pool is determined by NewSize & MaxNewSize parameters. Objects that survive first GC cycle gets transferred to another pool. Size of that pool is determined by parameter SurvivorRatio. If, garbage collection becomes a bottleneck, try customizing the generation pool settings.

    To set:

    1. Click through:

      Console | Servers | Application Servers | server_name | Additional Properties Process Definition | Java Virtual Machine | Custom Properties

    2. Enter the following values in the Generic JVM Arguments field:


      -XX:NewSize (lower bound)
      -XX:MaxNewSize (upper bound)
      -XX:SurvivorRatio=NewRatioSize .

    3. Click Apply or OK.

    4. Click Save on the console taskbar.

    5. Stop and restart the appserver.

    You can monitor using Tivoli Performance Viewer or the verbose:gc configuration setting.

    Default: NewSize=2m
    MaxNewSize=32m
    SurvivorRartio=2
    Recommended: For JVMs with more then 1 GB heap size set...
    -XX:newSize=640m
    -XX:MaxNewSize=640m
    -XX:SurvivorRatio=16

    ...or set 50-60% of total heap size to new generation pool.

  • Sun JDK 1.3 HotSpot -server warm-up

    Introduces adaptive JVM technology containing algorithms for optimizing byte code execution over time. The JVM runs in two modes

    1. -server
    2. -client.

    Performance is significantly enhanced if running in -server mode when a sufficient amount of time is allowed for a HotSpot JVM to warm up by performing continuous execution of byte code. In most cases, run the -server mode. This produces more efficient run-time execution over extended periods. Use the -client mode if you prefer a faster startup time and a smaller memory footprint, at the cost of lower extended performance.

    To set:

    Use the Java Virtual Machine page in the administrative console to change the -client or -server mode. One can monitor the process size and the server startup time to check the difference between -client and -server.

    Default: -server
    Recommended: -server

 

Applications

Several topics including Web modules, EJB modules, client modules, Web services and application services comprise the application programming model and provide numerous services supporting deployed applications. The Application Assembly Tool performance checklist introduces important topics for tuning during application assembly.

 

Databases

Tuning parameters vary according to the type of database you are using. DB2 tuning parameters are provided for your convenience. Since DB2 is not a WAS product and can change, consider these descriptions as suggestions.

 

Java messaging service

You can tune Java messaging service run-time components, resources, and the embedded messaging server through the administrative console with the following parameters:

  • Listener service

  • JMS resources

  • MQ

    • Includes the MQ folder where MQ is installed and indirectly where its data files reside since they are always under the directory WebSphereMQHome/data. Use this parameter during installation when extra disks are available.

    • To set:

      To view, search your system for a folder named MQ. Set during installation.

      Default: c:\Program Files\IBM\MQ\
      Recommended: Locate this directory away from any other disk input or output, on the fastest disk available. Redundant Array of Inexpensive Disks (RAID) is recommended.

  • Log file pages

    • Controls the size of the queue manager log files in number of pages. Use this parameter when high volumes of messages are being sent through a server.

    • To set:

      In the registry, navigate to HKEY_LOCAL_MACHINE | SOFTWARE | IBM | MQSeries | CurrentVision | Configuration | QueueManager | QM_name | Log | LogFilePages. For embedded JMS, set the LogFilePages to the desired value. Run the deletemq and createmq commands in the $WAS_HOME\bin directory to delete or recreate the queue manager. For external JMS, set LogFilePages to the desired value. Do this before creating the queue manager in the registry at HKEY_LOCAL_MACHINE | SOFTWARE | IBM | MQSeries | CurrentVision | Configuration | Log Defaults. Run the amqmdain regsec command to secure the registry value and create the queue manager.

      Default: External: 256, embedded: 512
      Recommended: There is no performance penalty for setting this value too high. Therefore, set the value to its maximum of 16384 pages.

  • Log buffer pages

    • Controls the size of the queue manager buffer to log file writes in number of pages. Use this parameter when high volumes of messages are being sent through a server.

    • To set:

      In the registry, navigate to HKEY_LOCAL_MACHINE | SOFTWARE | IBM | MQSeries | CurrentVision | Configuration | QueueManager | QM_name | Log | LogBufferPages. For embedded JMS, edit the createmq.properties setting LogFilePages in the $WAS_HOME\properties directory to the desired value. Run the deletemq and createmq commands to delete or recreate the queue manager. For external JMS, set LogFilePages to the desired value. Do this before creating the queue manager in the registry. Run the amqmdain regsec command to secure the registry value and create the queue manager.

      Default: 0
      Recommended: There is no performance penalty for setting this value too high. Therefore, set the value to its maximum of 512 pages.

  • Log primary files

    • Controls the number of primary or permanent log files for the queue manager. Use this parameter when high volumes of messages are being sent through a server.

    • To set:

      In the registry, navigate to HKEY_LOCAL_MACHINE | SOFTWARE | IBM | MQSeries | CurrentVision | Configuration | QueueManager | QM_name | Log | LogPrimaryFiles. For embedded JMS, edit the createmq.properties setting LogFilePages in the $WAS_HOME\properties directory to the desired value. Run the deletemq and createmq commands to delete or recreate the queue manager. For external JMS, set LogPrimaryFiles to the desired value. Do this before creating the queue manager in the registry. Run the amqmdain regsec command to secure the registry value and create the queue manager.

      Default: External: 3, embedded: 0
      Recommended: There is no performance penalty for setting this value too high. Set the value to its maximum of 63 pages.

  • Log secondary files

    • Controls the number of secondary log files for the queue manager. Secondary files are files created when the primary files are not enough and deleted when they are no longer needed.

    • To set:

      In the registry, navigate to HKEY_LOCAL_MACHINE | SOFTWARE | IBM | MQSeries | CurrentVision | Configuration | QueueManager | QM_name | Log | LogSecondaryFiles. For embedded JMS, edit the createmq.properties setting LogSecondaryFiles in the $WAS_HOME\properties directory to the desired value. Run the deletemq and createmq commands to delete or recreate the queue manager. For external JMS, set LogPrimaryFiles to the desired value. Do this before creating the queue manager in the registry. Run the amqmdain regsec command to secure the registry value and create the queue manager.

      Default: External: 2, embedded: 60
      Recommended: There is a limit of 63 total files from the primary and secondary combined and because secondary logs are slower, setting this 0 is ideal for performance.

  • Log default path

    • Controls the location of the queue manager log files. Use this parameter when high volumes of messages are sent through a server.

    • To set:

      In the registry, navigate to HKEY_LOCAL_MACHINE | SOFTWARE | IBM | MQSeries | CurrentVision | Configuration | QueueManager | QM_name | Log | LogDefaultPath. For embedded JMS, edit the createmq.properties setting LogPath in the $WAS_HOME\properties directory to the desired value. Run the deletemq and createmq commands to delete or recreate the queue manager. For external JMS, set LogDefaultPath to the desired value. Do this before creating the queue manager in the registry. Run the amqmdain regsec command to secure the registry value and create the queue manager.

      Default: WebSphereMQHome\log
      Recommended: It is ideal to have a disk dedicated to this task because MQ tries to keep the head of the disk positioned at the place in the file where it needs to write next. A fast RAID volume is best.

  • Default queue buffer size

    • Controls the size in bytes of an in-memory buffer for nonpersistent queues. Use this parameter when large message sizes are used, or large bursts of messages cause the queue to back up. If the queue backs up past this buffer, messages are flushed out to the disk.

    • To set:

      In the registry, navigate to HKEY_LOCAL_MACHINE | SOFTWARE | IBM | MQSeries | CurrentVersion | Configuration | QueueManager | QM_name | TuningParameters | DefaultQBufferSize. Embedded JMS is not currently supported; you need MQ5.3 CSD2 and an accompanying Version 5.0 fix. For external JMS, set DefaultQBufferSize to the desired value. Do this before creating the queue manager. Run the amqmdain regsec command to secure the registry value and create the queue manager.

      Default: 64K (registry key does not exist)
      Recommended: Set this parameter to accommodate the typical number of messages sitting on the queue at any given time. This should be numberOfMessages*(500+messageSizeInBytes). The maximum value is 100MB, but typically 1MB is enough.

  • Default persistent queue buffer size

    • Controls the size in bytes of an in-memory buffer for nonpersistent queues. Use this parameter whenever memory is available.

    • To set:

      In the registry, navigate to HKEY_LOCAL_MACHINE | SOFTWARE | IBM | MQSeries | CurrentVersion | Configuration | QueueManager | QM_name | TuningParameters | DefaultPQBufferSize. Embedded JMS is not currently supported; you need MQ5.3 CSD2 and an accompanying Version 5.0 fix. For external JMS, set DefaultPQBufferSize to the desired value. Create the queue manager. This is a permanent queue setting. To make a change, delete and recreate the queue.

      Default: 0 (registry key does not exist)
      Recommended: Set this parameter to accommodate the number of typical concurrently processed messages, plus a little more for read-ahead capabilities. Do this by calculating numOfCocurrentMessages*(msgSizeInBytes+500)*2. Typically, 1MB is enough.

  • Maximum channels

    • Controls the allowable number of concurrent CLIENT transport clients. Use this parameter when large numbers of clients are being used.

    • To set:

      In the registry, navigate to HKEY_LOCAL_MACHINE | SOFTWARE | IBM | MQSeries | CurrentVersion | Configuration | QueueManager | QM_name | Channels | MaxChannels. Embedded JMS is not currently supported; you need MQ5.3 CSD2 and an accompanying Version 5.0 fix. For external JMS, set MaxChannels to the desired value. Restart the queue manager.

      Default: External: 100 (registry key does not exist), embedded: 1000
      Recommended: Set this parameter high enough to contain the maximum number of concurrent JMS clients.

  • Channel application bind type

    • Controls if the channel application is an MQ FASTPATH application. Use this parameter at all times.

    • To set:

      In the registry, navigate to HKEY_LOCAL_MACHINE | SOFTWARE | IBM | MQSeries | CurrentVersion | Configuration | QueueManager | QM_name | Channels | MQIBindType. Embedded JMS is not currently supported; you need MQ5.3 CSD2 and an accompanying Version 5.0 fix. For external JMS, set MQIBindType to the desired value. Restart the queue manager.

      Default: Not FASTPATH (registry key does not exist)
      Recommended: FASTPATH

  • Embedded JMS server - Number of threads

    • With the embedded JMS publications and subscriptions server, this value is the number of threads to use for the publications and subscriptions matching engine, which matches publications to subscribers. Use this parameter when concurrent publications and subscriptions exist that would exceed the capacity of the default value.

    • To set:

      1. Click thru:

        Console | Servers | Application Servers | server_name | Server Component | JMS servers | Apply | Save
      2. Stop and restart the appserver.

      Default: 1
      Recommended: Set this value a little higher than the number of concurrent message publishers. If large numbers of subscribers exist, increasing this value can also provide some benefit.

 

Security

Enabling security decreases performance. The following tuning parameters give you considerations for increasing performance.

One can also read about Secure Sockets Layer performance tips and Tuning security configurations.

 

Object Request Broker

An ORB manages the interaction between clients and servers, using the IIOP. It supports client requests and responses received from servers in a network-distributed environment. You can tune the ORB with the following parameters:

The Object Request Broker tuning guidelines offer tips on using these parameters to tune the ORB.

 

XML parser definitions

  • Facilitates server startup by adding XML parser definitions to the jaxp.properties and xerxes.properties files in the ${install_root}/jre/lib directory. The XMLParserConfiguration value might change as new versions of Xerces are provided.

  • To set: Insert the following lines in both files: 

    javax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl 
javax.xml.parsers.DocumentBuildFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
org.apache.xerces.xni.parser.XMLParserConfiguration=org.apache.xerces.parsers.StandardParserConfiguration

    Default: None
    Recommended: None

 

Dynamic cache service

Using the dynamic cache service can improve performance. See Improving performance through the dynamic cache service for information about using the dynamic cache service and how it can affect your appserver performance.

 

Web container

One of the parts of each WAS is a Web container. To route servlet requests from the Web server to the Web containers, the product establishes a transport queue between the Web server plug-in and each Web container. The Web container is initially created with default property values suitable for simple Webapps. However, these values might not be appropriate for more complex Webapps. Using the following parameters, you can tune the Web container to fit the specific needs of your appserver.

 

EJB container

One of the parts of each appserver in WAS is an EJB container. An EJB container is automatically created when you create an application server. After the EJB container is deployed, you can use the following parameters to make adjustments that improve performance.

See also EJB queue tips

 

Session management

The installed default settings for session management are optimal for performance. See Tuning session management and Tuning parameter settings for more information about tuning session management.

 

Data sources

A data source is used to access data from the database. The following parameters reveal how the number of physical connections within a connection pool can change performance.

 

Hardware capacity and settings

These parameters include considerations for selecting and configuring the hardware on which the appservers can run.

 

Disk speed

Disk speed and configuration can have a dramatic effect on the performance of appservers that run applications that are heavily dependent on database support, that use extensive messaging, or are processing workflow. Using disk I/O subsystems that are optimized for performance, for example RAID array, are essential components for optimum application server performance in these environments.

To set: None

Default: None
Recommended: Spread the disk processing across as many disks as possible to avoid contention issues that typically occur with 1 or 2 disk systems.

 

Processor speed

In the absence of other bottlenecks, increasing the processor speed often helps throughput and response times.

To set: None

Default: None
Recommended: None

 

System memory

Increase memory to prevent the system from paging memory to disk, improving performance. Allow a minimum of 256MB of memory for each processor. Adjust the available memory when the system is paging and processor utilization is low because of the paging.

To set: None

Default: None
Recommended: 512MB per processor

 

Networks

Run network cards and network switches at full duplex. Running at half duplex decreases performance. Verify that the network speed can accommodate the required throughput.

To set: None

Default: None
Recommended: Make sure that 100MB is in use on 10/100 Ethernet networks.

 

Operating systems

  • AIX with DB2

    • Separating your DB2 log files from the physical database files can boost performance. One can also separate the logging and the database files from the drive containing the Journaled File System (JFS) service. AIX uses specific volume groups and file systems for the JFS logging.

    • To set use the AIX filemon utility to view all file system input and output, and to strategically select the file system for the DB2 logs. Then, set the DB2 log location according to DB2 logging.

      Default: The default location for the files is \home\<db2_user_name|\sqllib\db2dump.
      Recommended: Move the files to a disk that is separate from the DB2 data and that has minimum I/O activity.

  • AIX file descriptors (ulimit)

    • Specifies the number of open files permitted. The default setting is typically sufficient for most applications. If the value set for this parameter is too low, a Memory allocation error is displayed.

    • To set: Check the UNIX reference pages on ulimit for the syntax of different shells. To set the ulimit to 2000 for the KornShell shell (ksh), issue the ulimit -n 2000 command. Use the command ulimit -a to display the current values for all limitations on system resources.

      Default: For AIX systems, the default setting is 2000.
      Recommended: 2000

  • Other AIX information

    There are many other AIX operating system settings to consider that are not within the scope of this document. Additional settings you can adjust follow:

    • Adapter transmit and receive queue
    • TCP/IP socket buffer
    • IP protocol mbuf pool performance
    • Update file descriptors
    • Update the scheduler
    For more information about AIX, see Performance: Resources for Learning.

  • Solaris file descriptors (ulimit)

    • Specifies the number of open files permitted. If the value of this parameter is too low, a Too many files open error displays in the WAS stderr.log .

    • To set: Check the UNIX reference pages on ulimit for the syntax of different shells. For KornShell (ksh) use the ulimit -n 1024 command. Use the ulimit -a command to display the current values for all limitations on system resources.

      Default: None
      Recommended: 2000

  • Solaris TCP_TIME_WAIT_INTERVAL

    • Notifies the TCP/IP how long to keep closed connection control blocks. After the applications complete the TCP/IP connection, the control blocks are kept for the specified time. When high connection rates occur, a large backlog of the TCP/IP connections accumulate and can slow server performance. The server can stall during certain peak periods. If the server stalls, the netstat command shows that many of the sockets opened to the HTTP server are in the CLOSE_WAIT or FIN_WAIT_2 state. Visible delays can occur for up to four minutes, during which time the server does not send any responses, but CPU utilization stays high, with all of the activity in system processes.

    • To set use the get command to determine the current interval and the set command to specify an interval of 60 seconds. For example: 

      ndd -get /dev/tcp tcp_time_wait_interval     
ndd -set /dev/tcp tcp_time_wait_interval 60000

      Default: The Solaris default time wait interval is 2400000 milliseconds.
      Recommended: 60000 milliseconds.

  • Solaris TCP_FIN_WAIT_2_FLUSH_INTERVAL

    • Specifies the timer interval prohibiting a connection in FIN_WAIT_2 to remain in that state. When high connection rates occur, a large backlog of TCP/IP connections accumulate and can slow server performance. The server can stall during peak periods. If the server stalls, using the netstat command shows that many of the sockets opened to the HTTP server are in CLOSE_WAIT or FIN_WAIT_2 state. Visible delays can occur for up to four minutes, during which time the server does not send any responses, but CPU utilization stays high, with all of the activity in system processes.

    • How to view and set: One can set the current interval to 67.5 seconds by using the following commands: 

      ndd -get /dev/tcp tcp_fin_wait_2_flush_interval
ndd -set /dev/tcp tcp_fin_wait_2_flush_interval 67500

      Default: The Solaris default is 675000.
      Recommended: 67500

  • Solaris TCP_KEEPALIVE_INTERVAL

    • Specifies the timer interval prohibiting an active connection from staying in ESTABLISHED state if one of the peers never responds.

    • To set: Use the following commands to determine the current value or to set the value to 300 seconds:

      ndd -get /dev/tcp tcp_keepalive_interval ndd -set /dev/tcp tcp_keepalive_interval 300000

      Default: 7200000
      Recommended: 300000

  • Solaris kernel semsys:seminfo_semume

    • Limits the Max Semaphore undo entries per process. Because this setting specifies a maximum value, the parameter does not cause use of additional memory unless it is needed.

    • To set: This value is displayed as SEMUME if the /usr/sbin/sysdef command is run. There can be an entry in the /etc/system file for this tuning parameter. Set this parameter through the /etc/system entry as follows: 

      set semsys:seminfo_semume = 1024
      Default 10
      Recommended None

  • Solaris kernel semsys:seminfo_semopm

    • Displays as SEMOPM if the /usr/sbin/sysdef command is run. An entry in the /etc/system file can exist for this tuning parameter.

    • To set: Set this parameter through the /etc/system entry as follows: 

      semsys:seminfo_semopm = 200

      Default: None
      Recommended: 16384

  • Java Virtual machine virtual page size

    • Provides the current operating system characteristics of the process executable when you set the virtual page size.

    • To set: Set the virtual page size with the command chatr +pi64M +pd64M $WAS_HOME/java/bin/PA_RISC2.0/native_threads/java. Where 64M stands for 64MB.

      Default: None
      Recommended: 64MB

  • HP-UX 11i

    HP-UX 11i settings can be modified to significantly improve WAS performance. For additional information about the HP performance tuning parameters see Performance: Resources for learning.

    • Java Virtual Machine virtual page size

      • Setting the Java Virtual Machine page size to 64KB improves performance.

      • To set use the chatr +pi64M +pd64M $WAS_HOME/java/bin/PA_RISC2.0/native_threads/java command. The command output provides the current operating system characteristics of the process executable.

        Default: 4KB, if not assigned
        Recommended: 64KB

    • HP-UX 11i TCP_CONN_REQUEST_MAX

      • Specifies the maximum number of connection requests that the operating system can queue when the server does not have any available threads. When high connection rates occur, a large backlog of TCP/IP connection requests build up and client connections are dropped. Adjust this setting when clients start to timeout after waiting to connect. This situation can be verified by issuing the netstat -p tcp command. Look for the following value: connect requests dropped due to full queue

      • To set: Set this parameter by Using the ndd -set /dev/tcp tcp_conn_request_max 1024 command.

        Default: 20
        Recommended: 1024

    • HP-UX 11i kernel parameter recommendations

      • Use the following kernel parameter settings with DB2 or ORACLE for the best performance:

        Kernel parameter WAS setting DB2 setting Oracle setting
        maxuprc -- 512 --
        maxfiles 2,048 -- --
        maxfiles_lim 2,048 -- --
        nkthreads 10,000 -- --
        max_thread_proc 2,048 -- --
        nproc -- 1,028 --
        nflocks -- 8,192 --
        ninode -- 2,048 --
        nfile -- 8,192 --
        msgseg -- 32,767 --
        msgmnb -- 65,535 --
        msgmax -- 65,535 --
        msgtql -- 1,024 --
        msgmap -- 258 --
        msgmni -- 256 --
        msgssz -- 16 --
        semmni -- 512 70
        semmap -- 514 --
        semmns -- 1,024 200
        semmnu -- 1,024 --
        shmmax -- 966,367,642 1 GB
        shmmseg -- 16 10
        shmmni -- 300 100

      • To set use the HP-UX SAM utility to set the kernel parameters. See the documentation for your operating system for directions.

        Default: None
        Recommended: See table

    • HP-UX 11i kernel parameter recommendations for MQ 5.3

      • The embedded messaging uses MQ 5.3. The following are MQ 5.3 recommended kernel parameter settings:

        Kernel parameter Setting
        shmmax 536870912
        shmseg 1024
        shmmni 1024
        shmem 1
        sema 1
        semaem 16384
        semvmx 32767
        semmns 16384
        semmni 1024 (semmni < semmns)
        semmap 1026 (semmni +2)
        semmnu 2048
        semume 256
        msgmni 50
        msgtql 256
        msgmap 258 (msgtql +2)
        msgmax 4096
        msgmnb 4096
        msgssz 8
        msgseg 1024
        maxusers 32
        max_thread_proc 66
        maxfiles 1024
        nfile 10000

      • To set use the HP-UX SAM utility to set the kernel parameters. See the documentation for your operating system for directions.

        Default: None
        Recommended: See table

    • Generational garbage collection nursery size

      • WAS 5.0 ships with the the HP native JVM, which is based on the Sun Hotspot technology. One of its features is the use of generational garbage collection where the heap is divided into new and old generations. The appropriate size of the new generation or nursery must be determined using performance analysis tools such as Glance. If the nursery size is properly chosen, the overhead of garbage collection is reduced and throughput and response time improve.

      • To set use the -Xmn command at the generic Java options, for example, using -Xmn512m sets the nursery size to 512MB.

        Default: One-third the maximum heap size.
        Recommended: When several short-life objects are created, set the value to one-half the maximum heap size.

     

    Web servers

    Web server tuning parameters lists tuning parameters specific to Web servers. Because these are not WebSphere Application Server products be aware that the products can change and results vary.

    Tuning performance
    Tuning parameter hot list
    Queuing network
    SSL performance tips
    EJB method Invocation Queuing
    Java memory tuning tips
    Application assembly performance checklist
    Web server tuning parameters
    Choosing a topology for better performance
    Performance: Links
    Performance troubleshooting tips
    DB2 tuning parameters
    Setting custom properties for an HTTP transport

     

    WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

     

    IBM is a trademark of the IBM Corporation in the United States, other countries, or both.

     

    Tivoli is a trademark of the IBM Corporation in the United States, other countries, or both.

     

    AIX is a trademark of the IBM Corporation in the United States, other countries, or both.