What Influences the Performance of Application Servers?

Print-friendly Version

No matter which application server software you use, its performance is a critical measurement of cost-effectiveness and the end-user experience of your application. Despite the number of popular benchmarks available, no single benchmark can be used to predict the application server's performance, which depends on a variety of factors:

• The features of the application server

• The access paths into and out of the application server

• The application type

• The deployment topology

• Scalability

This article describes how each of those factors influences the overall performance of your application server.

Features of the Application Server

Application servers provide a variety of features, whose performance affect an application's response time.

In general, an application server environment provides these features either within or in conjunction with the application server:

• Enterprise JavaBeans (EJB) container -- A container in which the business logic resides. Subcomponents include container-managed persistence (CMP) and message-driven beans (MDB).

• Web container -- A container in which the presentation components are run.

• Java Message Service (JMS) -- An underlying layer that provides the messaging backbone.

• Java 2 Platform, Enterprise Edition (J2EE) Connector Architecture -- An infrastructure that connects to legacy systems through J2EE adapters.

• Authentication -- A subsystem that authenticates and authorizes accesses to the application.

• Load balancer -- A subsystem that distributes requests to various application servers and Web servers to enhance the horizontal scalability.

• Java Development Kit (JDK ) software -- The Java virtual machine in which the J2EE containers and other components run.

• Transaction manager -- A component that offers transaction-related capabilities, including a two-phase commit, dynamic resource enlistment, transaction monitoring and administration, as well as automatic transaction recovery.

• Java Database Connectivity (JDBC) drivers -- The drivers that connect to the database; they typically support connection pooling and data caching. Application servers usually also provide connection pooling for databases.

• Reverse proxy -- A component that redirects requests from the Web server to the application server and back.

• HTTP engine -- A component that handles requests from the HTTP path to the application server.

• Session persistence -- A component that provides session data in case of container failure.

• XML and Web service runtime -- A component that processes XML transactions and that transforms and executes tasks in accordance with requests from applications.

• Secure socket layer (SSL) -- The layer that performs encryption operations on the data exchanged with the application server.

• Server infrastructure -- Security, multiprocessing, multithreaded architecture, kernel threads, memory management, and such--all the components that provide virtual server support for the hosting of multiple Web sites from a single instance.

The following block diagram shows some of the core features offered by Sun ONE Application Server 7:

Access Paths

The application server resides at the heart of the data center. Applications that run on an application server can access other resources and can be accessed through a variety of paths. The response time from the server, when accessed from devices or when it access resources, impacts the application's performance. It is, therefore, important to understand the access paths:

• Inbound access paths

  • Hypertext Transport Protocol (HTTP/S) -- Traffic is light inbound but heavy outbound. Web services usually use this path and can have different profiles. Because encryption is CPU sensitive, use of SSL impacts performance.

  • JMS -- Traffic is bidirectional, moderate to heavy. You can also run JMS over different transports. The transport protocol that's in use affects performance.

  • Remote Method Invocation over Internet Inter-ORB [Object Request Broker] Protocol (RMI/IIOP) -- Traffic is bidirectional, light to moderate.

• Outbound access paths

  • Database -- Traffic is bidirectional, heavy from the database. Both the transaction type and the driver type impact performance.

  • J2EE connectors -- Traffic is bidirectional, heavy in both directions. Enterprise systems, such as SAP and PeopleSoft, use these links.

Application Types

Different types of applications use different components and access paths of the application server, both of which affect performance. The applications that run on an application server can be broadly classified as follows:

• Bank or e-commerce type applications -- These applications constitute the majority of those hosted on application servers. The main elements they rely on are JavaServer Pages (JSP) components, Java servlets, and HTTP access. Typically, security is achieved through authentication and SSL, with data requested from a database.

• Web service applications -- Many applications are built as Web services to enable interoperability and reuse. The main ingredients are HTTP access, XML transformations, JSP components, and Java servlets.

• Wireless applications -- These applications are accessed from multiple devices, typically with the underlying HTTP/S transport. Because many applications rely on alerts or notifications, JMS plays a key role in the applications. The main components are HTTP-WAP [Wireless Access Protocol], XML transformation, JSP components, and Java servlets.

• Desktop Java applications -- These are thick client applications that access, through the RMI/IIOP mechanism, the business logic hosted in the EJB components.

Each type of application has its own performance profile. To benchmark an application server, you would need to rely on performance benchmarks that represent that application. For example, you can use standardized benchmarks, such as ECPerf (now called SPECjAppServer) or the Web service measurement toolkit on the PushToTest site to understand the performance of application servers for specific types of application usage.

Deployment Topologies

The following two diagrams illustrate typical two-tier and three-tier deployment scenarios.

The multiple-tier model provides greater flexibility and tighter security. By taking advantage of its built-in SSL handling capabilities, Sun ONE Application Server 7 provides secure access to applications even when they are hosted on Tier 1. When you deploy applications with Sun ONE Application 7, you can direct the less security-sensitive requests to Tier 1 and more sensitive requests to Tier 2. In most enterprise deployments, you host the application server in Tier 2.

Scalability

You can scale applications either vertically (on a single machine) or horizontally (on multiple machines).

If you are using a large system, such as the Sun Enterprise 10000 (Starfire) machines, you should base your choice of application server on one that scales vertically. Doing so takes advantage of the caching that is available for multiple user requests.

Similarly, if you are using a Blades architecture, such as the Sun Blade workstations, you should base your choice of application server on one that scales horizontally. Doing so results in enhanced serviceability but involves more moving parts. Also, having a larger number of servers incurs overheads in maintenance, especially if the application components are distributed on different servers. As a rule, however, the components are easier to service, and the hardware is simpler to replace.

Sun ONE Application Server scales well--either vertically or horizontally. In weighing your choice, balance all the factors described here.

Conclusion

Many elements of the network topology--not just the J2EE containers--ultimately determine how well your application server performs. We recommend that, instead of relying only on industry benchmarks as your gauge, you also run benchmarks that mimic your application--such benchmarks are more reliable measurement tools.

For details on performance and tuning, see the documentation for Sun ONE Application Server.

For more information on the Sun ONE platform and its products, see Sun ONE for Developers

About the Authors

Rohit Valia has been product line manager for Sun ONE Application Server for two years. Before assuming his current position, he was a developer for PC networking and firewall and security technologies for a decade and worked closely with major enterprise customers in gathering and determining the requirements for Sun ONE Application Server 7.

Marina Sum is a staff writer for the Sun ONE Middleware Developer site. She has been writing for Sun for almost 14 years, mostly in the technical arena.