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 GlassFish Server.

[[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/toc.html#GSPTG[GlassFish Server Open Source
Edition 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/toc.html#GSRLN[GlassFish Server Open Source
Edition 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/toc.html#GSRLN[GlassFish Server Open Source
Edition 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/toc.html#GSING[GlassFish Server Open Source
Edition 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/toc.html#GSPTG[GlassFish Server Open Source
Edition 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 GlassFish Server.

|GlassFish Server Configuration a|
* Logging: Enable access log rotation.
* Choose the right logging level. WARNING is usually appropriate.
* Configure Java 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/toc.html#GSPTG[GlassFish Server
Open Source Edition Performance Tuning Guide]. +
For more information on configuration, see the link:../administration-guide/toc.html#GSADG[GlassFish
Server Open Source Edition 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 GlassFish Server, consider creating
a processor set and bind GlassFish Server 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 GlassFish Server 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 GlassFish
Server instance as unhealthy. If set too low and GlassFish Server'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
GlassFish Server 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 GlassFish Server 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.