docs/deployment-planning-guide/src/main/jbake/content/checklist.adoc - glassfish - Git at Google

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