Sun Java logo     Previous      Contents      Index      Next     

Sun logo
Sun Java System Application Server Enterprise Edition 8.1 2005Q1 Deployment Planning Guide 

Appendix A  
Checklist for Deployment

This appendix provides a checklist to get started on evaluation and production with the Application Server.

Table A-1  Checklist

Component/Feature

Description

Application

Determine the following requirements for the application to be deployed.

  • Required/acceptable response time.
  • Peak load characteristics.
  • Necessary persistence scope and frequency.
  • Session timeout in web.xml.
  • Failover and availability requirements.

For more information: Sun Java System Application Server Performance Tuning Guide.

Hardware

  • Use the same type of hardware to host HADB nodes.
  • Have necessary amounts of hard disk space and memory installed.
  • Use the sizing exercise to identify the requirements for deployment.

For more information: Sun Java System Application Server Release Notes

Operating System

  • Ensure that the product is installed on a supported platform.
  • Ensure that the patch levels are up-to-date and accurate.

For more information: Sun Java System Application Server Release Notes.

Network Infrastructure

  • Identify single points of failures and address them.
  • Make sure that the NICs and other network components are correctly configured.
  • Run ttcp benchmark test to determine if the throughput meets the requirements/expected result.
  • Setup rsh/ssh based your preference so that HADB nodes are properly installed.

For more information: Sun Java System Application Server Installation Guide.

Back-ends and other external data sources

Check with the domain expert or vendor to ensure that these data sources are configured appropriately.

System Changes/Configuration

  • Make sure that changes to /etc/system and its equivalent on Linux are completed before running any performance/stress tests.
  • Make sure the changes to the TCP/IP settings are complete.
  • By default, the system comes with lots of services pre-configured. Not all of them are required to be running. Turn off services that are not needed to conserve system resources.
  • On Solaris, use Setoolkit to determine the behavior of the system. Resolve any flags that show up.

For more information: Sun Java System Application Server Performance Tuning Guide.

Application Server and HADB Installation

  • Ensure that these servers are not installed on NFS mounted volumes.
  • Check for enough disk space and RAM when installing both Application Server and the HADB nodes on the same machine.
  • Check for enough independent disks when installing multiple HADB nodes on the same system.

For more information: Sun Java System Application Server Installation Guide.

HADB Configuration

  • Set the size of the HADB Data Device.
  • Define the DataBufferPoolSize.
  • Define the LogBufferSize.
  • Define the InternalBufferSize.
  • Set the NumberOfLocks.
  • Set optimum time-out values for various Application Server components.
  • Create the Physical layout of HADB nodes on the file system.

For more information on installing the HADB: Sun Java System Application Server High Availability Administration Guide.

Application Server Configuration

  • Logging: Enable access log rotation.
  • Choose the right logging level. WARNING is usually appropriate.
  • Configure J2EE containers using Admin Console.
  • Configure HTTP listeners using Admin Console.
  • Configure ORB threadpool using Admin Console.
  • If using Type2 drivers or calls involving native code, ensure that mtmalloc.so is specified in the LD_LIBRARY_PATH.
  • Ensure that the appropriate persistence scope and frequency are used and they are not overridden underneath in the individual Web/EJB modules.
  • Ensure that only critical methods in the SFSB are checkpointed.

For more information on tuning: Sun Java System Application Server Performance Tuning Guide.

For more information on configuration: Sun Java System Application Server Administration Guide.

Load balancer Configuration

  • Make sure the Web Server is installed.
  • Make sure the load balancer plug-in into the Web Server is installed.
  • Make sure patch checks is disabled.
  • Make sure RqThrottle, KeepAliveQuery* parameters. Lower the KeepAliveQuery* values are configured. The lower the value, the lower the latency is on lightly loaded systems. The higher the value, the higher the throughput is on highly loaded systems.

For more information: Sun Java System Application Server High Availability Administration Guide.

Java Virtual Machine Configuration

  • Initially set the minimum and maximum heap sizes to be the same, and at least one GB for each instance.
  • Refer to documentation on http://java.sun.com for configurable options in Java Hotspot JVM.
  • When running multiple instances of Application Server, consider creating a processor set and bind the Application Server to it. This helps in cases where the CMS collector is used to sweep the old generation.

Configuring time-outs in Load balancer

  • Response-time-out-in-seconds - Specifies how much time the load balancer waits before declaring an Application Server instance as unhealthy. This value needs to be set based on the response time characteristics of the application. If this value is too high, then the Web Server/Load balancer plug-in is going to wait for a long time before marking that Application Server instance as unhealthy. If the value for Response-time-out-in-seconds is set too low and if the Application Server’s response time crosses this threshold, the instance will be incorrectly marked as unhealthy.
  • Interval-in-seconds - Specifies the time interval in seconds after which unhealthy instances are checked to find out if they have returned to a healthy state. Too low a value generates extra traffic from the load balancer plug-in to Application Server instances and too high a value delays the routing of requests to the instance that has turned healthy.
  • Timeout-in-seconds - Specifies the duration for a response to be obtained for a health check request. This value needs to be adjusted based on the traffic among the systems in the cluster to ensure that the health check succeeds.

For more information: Sun Java System Application Server High Availability Administration Guide.

Configuring time-outs in HADB

  • sql_client_timeout - This variable specifies the wait time of SQLSUB for an idle client. For example, a client which has logged on, sends some requests, and then waits for user input. A client that has been idle for more than 30 minutes is assumed to be dead, and the session is terminated. Setting the value too low can cause SQL sessions to be aborted prematurely, while setting it too high can cause SQL sessions that are not idle, but have exited, to occupy resources. This in turn can prevent other SQL clients from logging on. When tuning this variable, also consider the settings of nsessions. If the HADB JDBC connection pool steady-pool-size is greater than max-pool-size, then idle-timeout-in-seconds can be set lower than the sql_client_timeout, so that the Application Server itself closes the connection before HADB closes the connection. The default value is 1800 seconds, which can be changed by editing the configuration file.
  • lock_timeout - Specifies the maximum time in milliseconds that a transaction waits for access to data. When exceeded, the transaction generates the error message: ”The transaction timed out.” Such time-outs are caused by transactions waiting for locks held by other transactions (deadlocks), and causing high server load. Do not set this value to below 500 ms. If you see the “transaction timed out” messages in the server log, then increase this value. Set the lock timeout value by adding a property to the HADB’s JDBC connection pool as: <property name=lockTimeout value="x" />. Default value is 5000 ms.
  • Querytimeout - Specifies the maximum time in milliseconds that the HADB waits for a query to execute. If you see exceptions in the server log consistently indicating the query time out, consider increasing this value. This value can be set by adding a property to the HADB’s JDBC connection pool as: <property name=QueryTimeout value="x" />. Default value is 30 sec.
  • loginTimeout - Specifies the maximum time in seconds that the client waits to login to the HADB. This can be set by adding a property to the HADB’s JDBC connection pool as: <property name=loginTimeout value="x" />. Default value is 10 sec.
  • MaxTransIdle - Specifies the maximum time in milliseconds that a transaction can be idle between sending a reply to the client and receiving the next request. This can be changed by adding a property to the HADB’s JDBC connection pool as: <property name=maxtransIdle value="x" />. Default value is 40 sec.

For more information: Sun Java System Application Server Performance Tuning Guide.

Configuring time-outs in Application Server

  • Max-wait-time-millis - Defines the wait time to get a connection from the pool before throwing an exception. Default is 60000 milliseconds. Consider changing this value in case of highly loaded systems where the size of the data being persisted is greater than 50 Kb.
  • Cache-idle-timeout-in-seconds - Applies to entity beans and stateful session beans. Defines the time the bean is allowed to be idle in the cache before it gets passivated.
  • Removal-timeout-in-seconds - The amount of time that the bean remains passivated, that is, idle in the backup store, is controlled by removal-timeout-in-seconds parameter. The default value is 60 minutes. This value needs to be adjusted based on the need for SFSB failover.
  • All of these values can be set by paying attention to the HADB’s JDBC connection pool setting max-wait-time-in-millis.

For more information: Sun Java System Application Server Performance Tuning Guide.

Tune VM Garbage Collection (GC)

GC pauses of four seconds or more can cause intermittent problems in persisting session state to HADB. To avoid this problem, tune the VM heap. In cases where even a single failure to persist data is unacceptable or when the system is not fully loaded, using CMS collector can help. Another option is to use the throughput collector.

These can be enabled by adding:

<jvm-options>-XX:+UseConcMarkSweepGC</jvm-options>

With the use of this option, you may experience a drop in throughput.

For more information: Sun Java System Application Server Release Notes

More information

JVM options:

http://java.sun.com/docs/hotspot/gc1.4.2/index.html

The Application Server document set available at

http://docs.sun.com



Previous      Contents      Index      Next     


Part No: 819-0078.   Copyright 2004 - 2005 Sun Microsystems, Inc. All rights reserved.