Sun Java System Application Server Enterprise Edition 8.1 2005Q1 Performance Tuning Guide |
Chapter 1
Overview of Sun Java System Application Server PerformanceYou can significantly improve performance of the Sun Java System Application Server and of applications deployed to it by adjusting a few deployment and server configuration settings. However, it is important to understand the environment and performance goals. An optimal configuration for a production environment might not be optimal for a development environment.
This chapter discusses the following topics:
Process OverviewThe following table outlines the overall administration process, and shows were performance tuning fits in the sequence.
Performance Tuning Sequence
Application developers should tune applications prior to production use. Tuning applications often produces dramatic performance improvements. System administrators perform the remaining steps in the following list after tuning the application, or when application tuning has to wait and you want to improve performance as much as possible in the meantime.
Ideally, follow this sequence of steps when you are tuning performance:
- Tune your application, described in Chapter 2, "Tuning Your Application."
- Tune the server, described in Chapter 3, "Tuning the Application Server."
- Tune the high availability database, described in Chapter 6, "Tuning for High-Availability."
- Tune the Java runtime system, described in Chapter 4, "Tuning the Java Runtime System."
- Tune the operating system, described in Chapter 5, "Tuning the Operating System."
Understanding Operational RequirementsBefore you begin to deploy and tune your application on the Application Server, it is important to clearly define the operational environment. The operational environment is determined by high-level constraints and requirements such as:
Application Architecture
The J2EE 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 J2EE 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 Application 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 Application 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 Application Server deployment, and when deploying a new business application to an existing application server deployment.
Security Requirements
Most business applications require security. This section discusses security considerations and decisions.
User Authentication and Authorization
Application users must be authenticated. The Application Server provides three different choices for user authentication: file-based, LDAP, and Solaris.
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 the Sun Java System Application Server Administration 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 Sun 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 J2EE 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.
Encryption
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 Application 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 Application 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 Application Server, behind the most secure firewall. Application Server provides secure reverse proxy plugins to enable integration with popular web servers. The Application 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 Application 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:
Hardware Resources
The type and quantity of hardware resources available greatly influence performance tuning and site planning.
The Application 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.
The Application 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.
General Tuning ConceptsSome key concepts that affect performance tuning are:
The following table describes these concepts, and how they are measured in practice. The left most column describes the general concept, the second column gives the practical ramifications of the concept, the third column describes the measurements, and the right most column describes the value sources.
Capacity Planning
The previous discussion guides you towards defining a deployment architecture. However, you determine the actual size of the deployment by a process called capacity planning. Capacity planning enables you to predict:
You can estimate these values through careful performance benchmarking, using an application with realistic data sets and workloads.
The basic steps in capacity planning are:
- Determine performance on a single CPU.
First determine the largest load that a single processor can sustain. You can obtain this figure by measuring the performance of the application on a single-processor machine. Either leverage the performance numbers of an existing application with similar processing characteristics or, ideally, use the actual application and workload in a testing environment. Make sure that the application and data resources are tiered exactly as they would be in the final deployment.
- Determine vertical scalability.
Determine how much additional performance you gain when you add processors. That is, you are indirectly measuring the amount of shared resource contention that occurs on the server for a specific workload. Either obtain this information based on additional load testing of the application on a multiprocessor system, or leverage existing information from a similar application that has already been load tested.
Running a series of performance tests on one to eight CPUs, in incremental steps, generally provides a sense of the vertical scalability characteristics of the system. Be sure to properly tune the application, Application Server, backend database resources, and operating system so that they do not skew the results.
- Determine horizontal scalability.
If sufficiently powerful hardware resources are available, a single hardware node may meet the performance requirements. However for better availability, you can cluster two or more systems. Employing external load balancers and workload simulation, determine the performance benefits of replicating one well-tuned application server node, as determined in step (2).
User Expectations
Application end-users generally have some performance expectations. Often you can numerically quantify them. To ensure that customer needs are met, you must understand these expectations clearly, and use them in capacity planning.
Consider the following questions regarding performance expectations:
- What do users expect the average response times to be for various interactions with the application? What are the most frequent interactions? Are there any extremely time-critical interactions? What is the length of each transaction, including think time? In many cases, you may need to perform empirical user studies to get good estimates.
- What are the anticipated steady-state and peak user loads? Are there are any particular times of the day, week, or year when you observe or expect to observe load peaks? While there may be several million registered customers for an online business, at any one time only a fraction of them are logged in and performing business transactions. A common mistake during capacity planning is to use the total size of customer population as the basis and not the average and peak numbers for concurrent users. The number of concurrent users also may exhibit patterns over time.
- What is the average and peak amount of data transferred per request? This value is also application-specific. Good estimates for content size, combined with other usage patterns, will help you anticipate network capacity needs.
- What is the expected growth in user load over the next year? Planning ahead for the future will help avoid crisis situations and system downtimes for upgrades.
Further Information
- For details on performance guidelines regarding J2EE applications, see
http://java.sun.com/blueprints/performance/index.html- For details on optimizing EJB components, see
http://developer.java.sun.com/developer/technicalArticles/ebeans/sevenrules/- For details on profiling, see the Application Server Developer’s Guide, chapter “Developing J2EE Applications,” specifically the section titled Profiling Tools.
- For more details on SNMP monitoring see the Application Server Administration Guide, the chapter on Monitoring and Managing Applications.
- For more details on the domain.xml file see the Application Server Administration Reference.
- For information on J2SE performance, see http://java.sun.com/docs/hotspot/index.html
- For general information on Java performance, see
http://java.sun.com/docs/performance