Previous Contents Index Next |
Sun Java System Application Server Enterprise Edition 7 2004Q2 System Deployment Guide

> ## Chapter 1
> Overview of Deployment

> This chapter describes what you need to know to set up your Sun Java™ System Application Server, Standard and Enterprise Edition the way that best meets your requirements.

> This chapter contains the following sections:

> - About Deployment
> - Phases of the Deployment Process

> ##

> About Deployment

> Successful deployment of complex applications on the Application Server requires that you consider practical aspects of the environment. In general, you should begin by assessing your goals for performance and availability. You should then plan the hardware, network, and resource configuration accordingly.

> Here are the important goals that you should consider while planning the deployment:

> - Throughput
> - Response time
> - Availability

> You gather information related to these goals and then analyze it to establish a processing threshold for your site.

> In considering performance, consider both—application server instances and the High Availability Database (HADB).

> The HADB uses the patented Always-On technology and works as the persistence store to provide high availability for web applications. It offers an ideal platform for delivering all types of session state persistence within an enterprise application server environment. For more information on configuring HADB, see Sun Java™ System Application Server Administration Guide.

> ### Throughput

> Throughput is the number of requests that Sun Java System Application Server can service in a given time period. For example requests per minute. You should estimate the maximum number of operations and transactions that the system needs to perform under peak load conditions. It is also useful to determine the operations and transactions per minute under steady state (typical) load conditions. This will help you to determine the network bandwidth needed, the number of application server instances required, and the number of HADB nodes required.

> You should also consider plans to increase capacity in the future.

> ### Response Time

> You should determine the acceptable response time from the system under heavy load. This has a direct bearing on hardware capacity planning.

> ### Availability

> Will your system be running 24 x 7? If there is a failure in the system, will your users notice it? Do you have a subset of applications that need to be available all the time whereas other applications will run only periodically? The answers to these questions determine your availability needs. You will have to build redundancy into the system to meet availability needs and avoid single points of failure.

> ##

> Phases of the Deployment Process

> The deployment process primarily comprises of the following three phases, each one building on the previous one.

> - Planning Your Environment
> - Selecting a Topology
> - Running Tests

> ### Planning Your Environment

> In the first phase of planning your deployment, determine how the Application Server fits into your overall enterprise. Central to planning your environment is the assessment of the goals discussed in About Deployment. You should establish performance goals related to throughput and response time. You also determine your availability goals.

> Based on the performance and availability goals, you consider the network requirements and the infrastructure requirements including hardware, storage, and network requirements.

> You may realize during this process that you should change the structure and components of your network to accommodate the needs of your Application Server. If your network structure cannot be changed at this time, use the environment planning process to determine how you can best deploy Application Server to fit in with your existing network.

> For more details on this phase of the planning process, see Chapter 2, "Planning your Environment."

> ### Selecting a Topology

> Once you have determined the performance, availability, network, and infrastructure requirements, you then select a topology that best meets your performance needs. A topology is the schematic arrangement of Application Server components and the communication flow between these components. The two recommended topologies (and their variations) are:

> - Co-located: The application server instance and the HADB node are on the same machine.
> - Separate Tier: The application server instance and the HADB node are on different machines.

> For more details on these topologies, see Chapter 3, "Selecting a Topology."

> ### Running Tests

> Once you configure the Application Server, you should deploy a representative sampling of applications and run tests to check whether your performance goals are met. If you are not able to reach your stated performance goals, use this phase to identify bottlenecks, fine-tune the system, and improve performance.

> As implementation of this phase is completely dependent on your particular environment, it is not covered in this guide.

> ##

> Understanding Session Persistence

> As an application session proceeds, there is often data that is part of the session that is not stored in a traditional database. An example of such data is the content of your shopping cart. Sun Java System Application Server provides the capability to save, or persist, this session state in a repository, so that if an application server instance experiences a failure, the session state can be recovered and the session can continue without loss of information.

> Sun Java System Application Server supports persistence of HTTP sessions and stateful session bean (SFSB) sessions. The persistence types ha, memory, and file are supported by the Sun Java System Application Server. When you set the persistence type to ha, the HADB is used as the persistence store for both HTTP and SFSB sessions. If the persistence type is not set to ha, SFSB sessions are persisted to the session store defined for passivated SFSBs. The memory and file settings have no effect on SFSBs.

> When an SFSB’s state is checked for changes that need to be saved, this is called checkpointing. If SFSB checkpointing is enabled, checkpointing generally occurs after any transaction involving the SFSB is completed, even if the transaction rolls back.

> For more information on enabling SFSB checkpointing, see the Sun Java System Application Server Developer’s Guide to Enterprise JavaBeans Technology.

> Apart from the number of requests being served by the Application Server, the session persistence configuration settings affect the number of requests received per minute by the HADB, as well as the session information in each request.

> The persistence settings can be defined for each application server instance. However, all application server instances in a single cluster must have the same persistence configuration. If you have deployed more than one Application Server cluster, it is not necessary for all clusters to have the same persistence configuration settings.

> For more information on configuring session persistence and its effect on performance, see Comparison of Persistence Scope Options.

> Note | Use the command cladmin to ensure that the session persistence settings are homogeneous for all instances in a cluster. For more information on using the cladmin command, see Sun Java System Application Server Administration Guide.

> Previous Contents Index Next

> Copyright 2004 Sun Microsystems, Inc. All rights reserved.