Application
|
Determine the following requirements for the application to be deployed.
|
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 see Sun GlassFish Enterprise Server 2.1 Release Notes
|
Operating System
|
|
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 see Sun GlassFish Enterprise Server 2.1 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 see Sun GlassFish Enterprise Server 2.1 Performance Tuning Guide.
|
Installation
|
|
HADB Configuration
|
|
Application Server Configuration
|
-
Logging: Enable access log rotation.
-
Choose the right logging level. WARNING is usually appropriate.
-
Configure Java EE 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, see Sun GlassFish Enterprise Server 2.1 Performance Tuning Guide.
For more information on configuration, see Sun GlassFish Enterprise Server 2.1 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.
-
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.
For more information, see Keep Alive in Sun GlassFish Enterprise Server 2.1 Performance Tuning 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.
-
See Java Hotspot VM Options for more information.
-
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 - How long the load balancer
waits before declaring an Application 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 an Application
Server instance as unhealthy. If set too low and the Application 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
Application 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.
For
more information, see Chapter 4, Configuring HTTP Load Balancing, in Sun GlassFish Enterprise Server 2.1 High Availability Administration Guide.
|
Configuring time-outs in HADB
|
-
sql_client_timeout - 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 terminate
SQL sessions prematurely. 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. Default value
is 1800 s.
-
lock_timeout - 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 - Maximum time in milliseconds that 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. Set this value
by adding the following property to HADB’s JDBC connection pool: <property
name=QueryTimeout value="x"\>. Default value is 30 s.
-
loginTimeout - Maximum time in seconds that the client waits
to login to HADB. Set this value by adding the following property to HADB’s
JDBC connection pool: <property name=loginTimeout value="x"\>.
Default value is 10 s.
-
MaxTransIdle - 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 s.
For more information: Sun Java System
Application Server Performance Tuning Guide.
|
Configuring time-outs in Application Server
|
-
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.
Adjust all of these values by paying attention to HADB’s JDBC
connection pool setting max-wait-time-in-millis. For more information, see Configuring the JDBC Connection Pool in Sun GlassFish Enterprise Server 2.1 High Availability Administration Guide.
|
Tune VM Garbage Collection (GC)
|
Garbage collection 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, 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.
|