| Skip Navigation Links | |
| Exit Print View | |
|
Oracle GlassFish Server 3.1 Performance Tuning Guide |
1. Overview of GlassFish Server Performance Tuning
Understanding Operational Requirements
User Authentication and Authorization
3. Tuning the GlassFish Server
4. Tuning the Java Runtime System
Before you begin to deploy and tune your application on the GlassFish Server, it is important to clearly define the operational environment. The operational environment is determined by high-level constraints and requirements such as:
The Java EE Application model, as shown in the following figure, is very flexible; allowing the application architect to split application logic functionally into many tiers. The presentation layer is typically implemented using servlets and JSP technology and executes in the web container.
Figure 1-1 Java EE Application Model
Moderately complex enterprise applications can be developed entirely using servlets and JSP technology. More complex business applications often use Enterprise JavaBeans (EJB) components. The GlassFish Server integrates the Web and EJB containers in a single process. Local access to EJB components from servlets is very efficient. However, some application deployments may require EJB components to execute in a separate process; and be accessible from standalone client applications as well as servlets. Based on the application architecture, the server administrator can employ the GlassFish Server in multiple tiers, or simply host both the presentation and business logic on a single tier.
It is important to understand the application architecture before designing a new GlassFish Server deployment, and when deploying a new business application to an existing application server deployment.
Most business applications require security. This section discusses security considerations and decisions.
Application users must be authenticated. The GlassFish Server provides a number of choices for user authentication, including file-based, administration, LDAP, certificate, JDBC, digest, PAM, Solaris, and custom realms.
The default file based security realm is suitable for developer environments, where new applications are developed and tested. At deployment time, the server administrator can choose between the Lighweight Directory Access Protocol (LDAP) or Solaris security realms. Many large enterprises use LDAP-based directory servers to maintain employee and customer profiles. Small to medium enterprises that do not already use a directory server may find it advantageous to leverage investment in Solaris security infrastructure.
For more information on security realms, see Administering Authentication Realms in Oracle GlassFish Server 3.1 Security Guide.
The type of authentication mechanism chosen may require additional hardware for the deployment. Typically a directory server executes on a separate server, and may also require a backup for replication and high availability. Refer to the Oracle Java System Directory Server documentation for more information on deployment, sizing, and availability guidelines.
An authenticated user’s access to application functions may also need authorization checks. If the application uses the role-based Java EE authorization checks, the application server performs some additional checking, which incurs additional overheads. When you perform capacity planning, you must take this additional overhead into account.
For security reasons, sensitive user inputs and application output must be encrypted. Most business-oriented web applications encrypt all or some of the communication flow between the browser and GlassFish Server. Online shopping applications encrypt traffic when the user is completing a purchase or supplying private data. Portal applications such as news and media typically do not employ encryption. Secure Sockets Layer (SSL) is the most common security framework, and is supported by many browsers and application servers.
The GlassFish Server supports SSL 2.0 and 3.0 and contains software support for various cipher suites. It also supports integration of hardware encryption cards for even higher performance. Security considerations, particularly when using the integrated software encryption, will impact hardware sizing and capacity planning.
Consider the following when assessing the encryption needs for a deployment:
What is the nature of the applications with respect to security? Do they encrypt all or only a part of the application inputs and output? What percentage of the information needs to be securely transmitted?
Are the applications going to be deployed on an application server that is directly connected to the Internet? Will a web server exist in a demilitarized zone (DMZ) separate from the application server tier and backend enterprise systems?
A DMZ-style deployment is recommended for high security. It is also useful when the application has a significant amount of static text and image content and some business logic that executes on the GlassFish Server, behind the most secure firewall. GlassFish Server provides secure reverse proxy plugins to enable integration with popular web servers. The GlassFish Server can also be deployed and used as a web server in DMZ.
Is encryption required between the web servers in the DMZ and application servers in the next tier? The reverse proxy plugins supplied with GlassFish Server support SSL encryption between the web server and application server tier. If SSL is enabled, hardware capacity planning must be take into account the encryption policy and mechanisms.
If software encryption is to be employed:
What is the expected performance overhead for every tier in the system, given the security requirements?
What are the performance and throughput characteristics of various choices?
For information on how to encrypt the communication between web servers and GlassFish Server, see Chapter 3, Administering Message Security, in Oracle GlassFish Server 3.1 Security Guide.
GlassFish Server 3.1 enables multiple GlassFish Server instances to be clustered to provide high availability through failure protection, scalability, and load balancing.
High availability applications and services provide their functionality continuously, regardless of hardware and software failures. To make such reliability possible, GlassFish Server 3.1 provides mechanisms for maintaining application state data between clustered GlassFish Server instances. Application state data, such as HTTP session data, stateful EJB sessions, and dynamic cache information, is replicated in real time across server instances. If any one server instance goes down, the session state is available to the next failover server, resulting in minimum application downtime and enhanced transactional security.
GlassFish Server provides the following high availability features:
HTTP Load Balancer Plug-in
High Availability Session Persistence
High Availability Java Message Service
RMI-IIOP Load Balancing and Failover
See Tuning High Availability Persistence for high availability persistence tuning recommendations.
See the Oracle GlassFish Server 3.1-3.1.1 High Availability Administration Guide for complete information about configuring high availability clustering, load balancing, and failover features in GlassFish Server 3.1.
The type and quantity of hardware resources available greatly influence performance tuning and site planning.
GlassFish Server provides excellent vertical scalability. It can scale to efficiently utilize multiple high-performance CPUs, using just one application server process. A smaller number of application server instances makes maintenance easier and administration less expensive. Also, deploying several related applications on fewer application servers can improve performance, due to better data locality, and reuse of cached data between co-located applications. Such servers must also contain large amounts of memory, disk space, and network capacity to cope with increased load.
GlassFish Server can also be deployed on large “farms” of relatively modest hardware units. Business applications can be partitioned across various server instances. Using one or more external load balancers can efficiently spread user access across all the application server instances. A horizontal scaling approach may improve availability, lower hardware costs and is suitable for some types of applications. However, this approach requires administration of more application server instances and hardware nodes.
A single GlassFish Server installation on a server can encompass multiple instances. A group of one or more instances that are administered by a single Administration Server is called a domain. Grouping server instances into domains permits different people to independently administer the groups.
You can use a single-instance domain to create a “sandbox” for a particular developer and environment. In this scenario, each developer administers his or her own application server, without interfering with other application server domains. A small development group may choose to create multiple instances in a shared administrative domain for collaborative development.
In a deployment environment, an administrator can create domains based on application and business function. For example, internal Human Resources applications may be hosted on one or more servers in one Administrative domain, while external customer applications are hosted on several administrative domains in a server farm.
The GlassFish Server supports virtual server capability for web applications. For example, a web application hosting service provider can host different URL domains on a single GlassFish Server process for efficient administration.
For detailed information on administration, see Oracle GlassFish Server 3.1 Administration Guide.
|