|
| Sun ONE Application Server 7 Performance Tuning Guide |
About Sun ONE Application Server PerformanceIn this module, the following topics are discussedmodule:
- Why Tune Application Server?
- Understanding Operational Requirements
- Capacity Planning
- Performance Tuning Sequence
- Configuration Files
Why Tune Application Server?
Performance can be significantly enhanced by adjusting a few deployment descriptor settings or server configuration file modifications. However, it is important to understand the environment and performance goals. An optimal configuration for a production environment may not necessarily be optimal for a development environment. This guide helps you to understand the tuning and sizing options available, providing you the capabilities and practices to obtain the best performance out of your Sun ONE Application Server.
The process architecture of Sun ONE Application Server is represented in the following figure:
Figure: Sun ONE Application Server Process Architecture for a Single Domain
Understanding Operational Requirements
Before you begin to deploy and tune your application on the Sun ONE 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 JSPs and executes in the web container.
Figure: J2EE Application Model
It is not uncommon to see moderately complex enterprise applications developed entirely using Servlets and JSPs. More complex business applications are often implemented using EJBs. The Sun ONE Application Server integrates the web and EJB containers, in a single process. Local access to EJBs from Servlets is very efficient. However, some application deployment may require EJBs 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 Sun ONE Application Server in multiple tiers, or simply host both the presentation and business logic on a single tier.
It is important that the server administrator understand the application architecture before designing a new application server deployment, or while deploying a new business application to an existing application server deployment.
Security Requirements
Most business applications require security. The various security considerations and available choices are discussed in this section.
User Authentication and Authorization
Application users must be authenticated. Sun ONE Application Server provides three different choices for user authentication.
The default file based security realm is suitable for developer environments, where new applications are being developed and tested. At deployment time, the server administrator can choose between the LDAP or Unix security realms.
LDAP stands for Lighweight Directory Access Protocol. 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 also find that it is advantageous to leverage their investment in Solaris security infrastructure.
More information on how to integrate with various security realms, can be found in the Sun ONE Application Server Administrator's Guide to Security.
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 ONE Directory Server documentation for more information on deployment, sizing, and availability guidelines.
An authenticated user's access to various application functions may also need authorization checks. If the application uses the role based J2EE authorization checks, some additional checking is performed by the application server. This places additional overheads, which need to be accounted for while doing capacity planning.
Encryption
For security reasons, sensitive user inputs and application output must be transmitted in an encrypted form. Most business oriented web applications encrypt all or some of the communication flow between the browser and Application server, if required. Online shopping applications, typically do not encrypt traffic, except when the user is completing a purchase or supplying private data. Portal applications such as news and media typically do not employ encryption. SSL is the most common security framework on internet, and is supported by many browsers and application servers.
Sun ONE 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. While considering the encryption needs for a deployment, the administrator needs to consider the following:
- 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 is the percentage of information that 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 when the deployment has high security requirements. It is also useful when the application has a significant amount of static text and image content (which need not be encrypted in most cases and is served from the web server deployed in DMZ) and has a small but significant amount of business logic which executes on the Application server, behind the most secure firewall. Secure reverse proxy plugins are supplied with Sun ONE Application Server to enable popular web servers to integrate with Sun ONE Application Server. Since Sun ONE Application Server is also a full fledged web server, it can 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 Sun ONE Application Server support SSL encryption between the web server and application server tier. If this is enabled the administrator needs to perform hardware capacity planning based on the encryption policy and mechanisms.
- If software encryption is to be employed, what is the expected performance overhead, at every tier in the system, given the security requirements.
- If hardware encryption is to be employed, what are the performance and throughput characteristics of various choices?
Note For information on how to encrypt the communication between Web servers and Sun ONE Application Server, please refer to Sun ONE Application Server Administrator's Guide.
Application Usage
Every application user will have some expectations with respect to application performance. Often they can be numerically quantified. The server administrator must understand these expectations clearly, and use them in capacity planning to ensure that the deployment will meet customer needs, when completed.
With regard to performance, you need to consider the following:
- What are the required average response times expected by the end users 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, empirical user studies may need to be performed to come up with 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 load peaks are observed? While there may be several million registered customers for an online business, typically only a fraction of them are logged in and performing business transactions, at any point in time. 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 interesting time based patterns.
- What is the average and peak amount of data transferred per request? This is also very application specific. Good estimates for content size, combined with other usage patterns, will help the administrator anticipate network capacity needs.
- What is the expected growth in user load over the next 12 months? Planning ahead for the future, will help avoid crisis situations and system downtimes for upgrades.
Hardware Resources
The type and quantity of hardware resources at the disposal of the administrator greatly influence performance tuning and site planning.
Sun ONE Application Server provides excellent vertical scalability. It can scale to efficiently utilize up to 12 high performance CPUs, using just one application server process. The smaller number of application server instances provides ease of maintenance and lowered administration costs. Also, deploying several related applications on fewer application servers, can lead of performance improvements, due to better data locality, and reuse of cached data between collocated applications.Such servers must also contain large amounts of memory, disk and network capacity in order to cope with increased load.
Sun ONE Application Server can also be deployed on large "farms" of smaller hardware units. Business Applications can be partitioned across various server instances. By employing one or more external load balancers, user access can be efficiently spread across all the application server instances. A horizontal scaling approach may improve availability, lower hardware costs and is certainly suitable for certain types of applications. However, greater number of application server instances and hardware nodes need to be administered
Administration
A single Sun ONE Application Server installation on a server can be used to created several instances. One or more instances are administered by a single Administration Server, and this grouping of the Administration server and administered instances is called a "Domain." Several administrative domains can be created to permit different people to independently administer groups of application server instances.
A single instance domain may be created to create a "sandbox" for a particular developer in a developer environment. In this scenario, each developer administers his/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, the server administrator could create administrative 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.
Sun ONE Application Server supports Virtual Server capability for web applications. A web application hosting service provider, may wish to host different URL domains on a single Sun ONE Application Server process, for efficient administration. The server administrator must determine, if they need to or want to use this capability.
At this point, the server administrator should be able to list all the applications, and their broad performance characteristics, security requirements and sketch the deployment environment, at a high level. The next step is to understand how to predict performance and do capacity planning.
Capacity Planning
The previous discussion guides the administrator towards defining a preferred deployment architecture. However, the actual size of the deployment is determined by a process called capacity planning.
How does one predict either the capacity of a given hardware configuration or predict the hardware resources required to sustain a specified application load and customer criteria? This is done by a careful performance benchmarking process, using the real application and with realistic data sets and workload simulation.The basic steps are briefly described below.
- Determine performance on a single CPU
You need to first determine the largest load that can be sustained with a known amount of processing power. You can obtain this figure by measuring the performance of the application on a uniprocessor machine. You can 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 configured in a tiered manner, exactly as they would be in the final deployment.
- Determine vertical scalability
You need to know exactly how much additional performance is gained 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. You can 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. Make sure that the application, application server and backend database resources, operating system etc., are properly tuned so that they not skew the results of this study.
- Determined horizontal scalability
If sufficiently powerful hardware resources are available, a single hardware node may meet the performance requirements. However for better service availability, two or more systems may be clustered. Employing an external load balancers and workload simulation, determine the performance benefits of replicating one well tuned application server node, as determined in step (2).
The following table describes the steps in capacity planning:
Performance Tuning Sequence
Tuning a deployment may be performed in the following sequence:
- Tuning Your Application
- Tuning Sun ONE Application Server
- Tuning the Java Runtime System
- Tuning the Operating Systemmodules
Configuration Files
The files init.conf, obj.conf, and server.xml are Sun ONE Application Server configuration files containing many attributes that can be modified to improve performance. They are frequently mentioned within this guide and can be found in the directory:
<APPSERVER_HOME>/appserv/domains/<DOMAIN_NAME>/<SERVER_NAME>/config/
APPSERVER_HOME is the installation directory for the Sun ONE Application Server. DOMAIN_NAME and SERVER_NAME refer to the domain and server names for the server instance to be configured.
The following figure shows the configuration file for a given instance.
Figure: Sun ONE Application Server Configuration Files
The config/backup directories contain a replica of the server configuration files. These files are created by the administration server instance. In general, users should not change these files by hand. If the config files are edited by hand, make a copy of the files and place them in the backup directory. Additionally, the server instance should be restarted.
Logging and Performance
The Sun ONE Application Server produces log messages and exception stack trace output that gets written to the log file. These log messages and exception stacks can be found in the logs directory of the instance. Naturally, the volume of log activity can impact server performance; particularly in benchmarking situations.
By default, the log level is set to INFO. The log level can be set for all the server subsystems by changing the attribute level in the log_service element. You can override the logging level by adjusting it at a particular subsystem. For example, mdb_container can produce log messages at a different lever than server default by adjusting the log_level attribute under the mdb_container element. To get more debug messages, set the log level to FINE, FINER, or FINEST. Under benchmarking conditions, it may be appropriate to set the log level to SEVERE.