JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle GlassFish Server 3.1 Deployment Planning Guide
search filter icon
search icon

Document Information

Preface

1.  Product Concepts

2.  Planning your Deployment

Establishing Performance Goals

Estimating Throughput

Estimating Load on GlassFish Server Instances

Maximum Number of Concurrent Users

Think Time

Average Response Time

Requests Per Minute

Planning the Network Configuration

Setting Up Traffic Separation

Estimating Bandwidth Requirements

Calculating Bandwidth Required

Estimating Peak Load

Choosing Network Cards

Planning for Availability

Rightsizing Availability

Using Clusters to Improve Availability

Adding Redundancy to the System

Identifying Failure Classes

Planning Failover Capacity

Design Decisions

Designing for Peak or Steady State Load

System Sizing

Sizing the Administration Thread Pool

Planning Message Queue Broker Deployment

Multi-Broker Clusters

Master Broker and Client Synchronization for Conventional Clusters

Configuring GlassFish Server to Use Message Queue Brokers

Java Message Service Type

Embedded Java Message Service

Local Java Message Service

Remote Java Message Service

Managing JMS with the Administration Console

Managing JMS with asadmin

Default JMS Host

Example Deployment Scenarios

Default Deployment

Using a Message Queue Broker Cluster with a GlassFish Server Cluster

Specifying an Application-Specific Message Queue Broker Cluster

Application Clients

3.  Checklist for Deployment

Index

Design Decisions

Design decisions include whether you are designing the system for peak or steady-state load, the number of machines in various roles and their sizes, and the size of the administration thread pool.

The following topics are addressed here:

Designing for Peak or Steady State Load

In a typical deployment, there is a difference between steady state and peak workloads:

How often the system is expected to handle peak load will determine whether you want to design for peak load or for steady state.

If peak load occurs often—say, several times per day—it may be worthwhile to expand capacity to handle it. If the system operates at steady state 90 percent of the time, and at peak only 10 percent of the time, then it may be preferable to deploy a system designed around steady state load. This implies that the system’s response time will be slower only 10 percent of the time. Decide if the frequency or duration of time that the system operates at peak justifies the need to add resources to the system.

System Sizing

Based on the load on the GlassFish Server instances and failover requirements, you can determine the number of applications server instances (hosts) needed. Evaluate your environment on the basis of the factors explained in Estimating Load on GlassFish Server Instances to each GlassFish Server instance, although each instance can use more than one Central Processing Unit (CPU).

Sizing the Administration Thread Pool

The default admin-thread-pool size of 50 should be adequate for most cluster deployments. If you have unusually large clusters, you may need to increase this thread pool size. In this case, set the max-thread-pool-size attribute to the number of instances in your largest cluster, but not larger than the number of incoming synchronization requests that the DAS can handle.