type=page
status=published
title=Checklist for Deployment
prev=planning.html
~~~~~~

= Checklist for Deployment

[[GSPLG00003]][[abfeq]]


[[checklist-for-deployment]]
== 3 Checklist for Deployment

This appendix provides a checklist to get started on evaluation and
production with the {productName}.

[[sthref7]][[checklist]]

=== Checklist

[[sthref8]][[sthref9]]

Table 3-1 Checklist

[width="100%",cols="<23%,<77%",options="header",]
|===
|Component/Feature |Description
|Application
a|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 see the link:performance-tuning-guide.html#GSPTG[
{productName} Performance Tuning Guide].

|Hardware
a|
* Have necessary amounts of hard disk space and memory installed.
* Use the sizing exercise to identify the requirements for deployment.

For more information see the link:release-notes.html#GSRLN[{productName} Release Notes]

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

For more information see the link:release-notes.html#GSRLN[{productName} Release Notes]

|Network Infrastructure
a|
* 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 `ssh` based your preference.

For more information see the link:installation-guide.html#GSING[{productName} 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
a|
* 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 see the link:performance-tuning-guide.html#GSPTG[{productName} Performance Tuning Guide].

|Installation
a|
* Ensure that these servers are not installed on NFS mounted volumes.
* Check for enough disk space and RAM when installing {productName}.

|{productName} Configuration
a|
* Logging: Enable access log rotation.
* Choose the right logging level. WARNING is usually appropriate.
* Configure Jakarta EE containers using the Administration Console.
* Configure HTTP listeners using the Administration Console.
* Configure ORB threadpool using the Administration 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, see the link:performance-tuning-guide.html#GSPTG[{productName} Performance Tuning Guide].

For more information on configuration, see the link:administration-guide.html#GSADG[{productName} Administration Guide].

|Load balancer Configuration
a|
* 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.
* Lower the value of the `KeepAliveQuery` parameter. 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.

|Java Virtual Machine Configuration
a|
* Initially set the minimum and maximum heap sizes to be the same, and
  at least one GB for each instance.
* See http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html[
  Java Hotspot VM Options]
(`http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html`)
  for more information.
* When running multiple instances of {productName}, consider creating
  a processor set and bind {productName} to it. This helps in cases
  where the CMS collector is used to sweep the old generation.

|Configuring time-outs in the load balancer
a|
* Response-time-out-in-seconds - How long the load balancer waits before
  declaring a {productName} instance unhealthy. Set this value based on
  the response time of the application. If set too high, the Web Server
  and load balancer plug-in wait a long time before marking a {productName} instance as unhealthy. If set too low and {productName}'s
  response time crosses this threshold, the instance will be incorrectly
  marked as unhealthy.
* Interval-in-seconds - Time 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
  {productName} instances and too high a value delays the routing of
  requests to the instance that has turned healthy.
* Timeout-in-seconds - Duration for a response to be obtained for a
  health check request. Adjust this value based on the traffic among the
  systems in the cluster to ensure that the health check succeeds.

|Configuring time-outs in {productName}
a|
* Max-wait-time-millis - Wait time to get a connection from the pool
  before throwing an exception. Default is 6 s. Consider changing this
  value for highly loaded systems where the size of the data being
  persisted is greater than 50 KB.
* Cache-idle-timeout-in-seconds - Time an EJB is allowed to be idle in
  the cache before it gets passivated. Applies only to entity beans and
  stateful session beans.
* Removal-timeout-in-seconds - Time that an EJB remains passivated (idle
  in the backup store). Default value is 60 minutes. Adjust this value
  based on the need for SFSB failover.

|Tune VM Garbage Collection (GC)
a| Garbage collection pauses of four seconds or more can cause intermittent
problems in persisting session state. 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, use the CMS
collector or the throughput collector.

These can be enabled by adding: +
`<jvm-options>-XX:+UseConcMarkSweepGC</jvm-options>`

This option may decrease throughput.
|===