Welcome!

Websphere Authors: Kevin Benedict

Related Topics: Websphere

Websphere: Article

WebSphere 5.0: What's New on the Performance Front

WebSphere 5.0: What's New on the Performance Front

IBM WebSphere Application Server (WAS) version 5.0 continues the tradition of improved performance from release to release. These improvements come from several key areas, which include:

  • WAS's implementation of new J2EE 1.3 APIs, notably EJB 2.0
  • Web services using SOAP
  • Dynamic caching and edge componentry
  • HTTP session management
  • Extensions for the enterprise
WAS 5.0 complements these performance enhancements with an enhanced collection of runtime tools for performance, including Java Management Extension (JMX) interfaces for performance monitoring and performance advice. This article presents these features, highlighting their contribution to WAS 5.0's performance.

J2EE 1.3
WAS 5.0 supports the J2EE 1.3 programming model. The most significant area of performance advancement is within the EJB 2.0 portion of J2EE 1.3. There are two aspects of EJB 2.0 that support building higher-performing EJB-based applications: local interfaces and container-managed entities.

Local Interfaces
EJB 2.0 local interfaces provide optimized EJB-to-EJB access. By definition, EJB 2.0 local interfaces are local method calls that use call-by reference semantics. Unlike traditional EJB remote or "location-transparent" methods, local interface methods have no intramethod overhead and do not create copies of parameter or return objects. Lab measurements show a 20% to 2x improvement, depending on the size and complexity of parameters and/or return values.

Container-Managed Entities
Container-managed entities receive a boost in both usability and performance by allowing for container-managed relationships (CMR). CMRs define a relationship pattern between EJBs. Consider an application in which customers place orders. There is a relationship between customers and orders, in that every time the application accesses the Customer EJB, it also accesses the orders that a given customer has made. Furthermore, using the IBM WebSphere Studio tooling, you can define a read-ahead policy to improve the performance by preloading associated objects.

Figure 1 shows an association between customers and orders. The implementation is a CMR with one customer having many orders. A read-ahead hint on this relationship optimizes performance by preloading orders with the related customer in one generated SQL SELECT statement with a SQL JOIN for both underlying tables. This halves the number of database accesses for this logically related data. Using the read-ahead hint yielded a 10-15% performance improvement in lab measurements involving similar CMRs with 10 associated objects.

Base EJB 2.0 supports one read-ahead hint per association. WebSphere Application Server Enterprise Edition adds the capability to define multiple read-ahead hints per CMR relationship. This added capability is part of application profiling, discussed later in this article.

Web Services
The most significant Web services performance optimization is in the SOAP support in the Web Services Technology Preview. In particular, the JAX-RPC, which is the standard programming interface to Web services, uses an optimized Apache Axis as the core of the WAS Web services stack. Early benchmarks on this base exhibit significant improvement in performance, depending on the complexity of the SOAP messages. This is illustrated in Figure 2, which shows a 2x improvement in throughput between WAS 4.0 and the WAS 5.0 Technology Preview. In this scenario SOAP messages containing a Java array containing 100 strings are exchanged between a Microsoft .NET client and WAS.

The new Axis implementation also allows for pluggable XML parsers following the Java API for XML Processing (JAXP) standard. By default, WAS configures the standard Xerces parser as the parser used for Web services. However, specialized parsers can be placed under JAXP to produce even better performance results for Web services. IBM is currently testing specialized parsers for future updates. Upgrading to a faster parser is transparent to the applications using Web services.

Dynamic Caching and Edge Components
The most efficient interaction is the interaction never done. This is the spirit of dynamic caching. WAS 5.0 introduces a powerful set of integrated cache-enabled APIs and services within the application server and Edge Server components, as shown in Figure 3. Utilizing these APIs and services can easily lead to doubling or tripling your application's performance.

WAS Caching Programming Model
WAS 5.0 allows for result caching of servlets/JSPs and CMP Entities and EJBs. Caching of SOAP responses for Web services and caching of command results (when using the com.ibm.websphere.command interface) are also supported. Resulting servlet/JSP fragments can also be cached on Edge Servers using Edge Side Includes (ESI) technology.

Result caching of servlet/JSP, EJB, and SOAP requests can be accomplished without the use of explicit caching APIs. Caching policies are described declaratively, using XML deployment descriptors. For example, the WebSphere Application Assembly Tool (AAT) is used to express how to cache and invalidate cached content. A Cache policy XML file, cachespec.xml, provides the caching metadata required by the dynamic caching service.

WAS Dynamic Caching Service
The runtime foundation for caching in WAS is the WebSphere dynamic caching service (Dynacache). Dynacache is a Java object cache that caches objects directly in WAS's (i.e., the JVM's) memory with the ability to "overflow" objects to disk to avoid over-utilizing memory. Using the Replication domain facility in WAS, results are optionally replicated across a cluster to avoid expensive regeneration on each server. Invalidation events to remove stale data from Dynacache are distributed using the same facility.

External Caches
Contents in Dynacache can be shared with external caches, including the Caching Proxy Server (which is a WebSphere Edge Component), the IBM HTTP Server Cache Accelerator (HTTP kernel cache), or the WebSphere Web Server Plug-in (which plugs into most standard HTTP servers). These external caches support full-page caching of content generated by servlets/JSPs.

In addition, WAS 5.0 supports distributed fragment caching and assembly based upon the open ESI technology (www.esi.org). This enables WAS customers to improve delivery of personalized, dynamic Web content by exploiting ESI-capable "edge" servers, including the WAS Web server plug-in and in-network service providers such as Akamai. For example, with this powerful new feature, a page composed from a collection of servlets/JSPs (e.g., a portal-style page) can be assembled in the Web server from either cached or noncached components. By marking cached JSP/servlet results as "edgeable," using the assembly tool or by directly editing cachespec.xml, the corresponding cached results within Dynacache are copied into the plug-in memory (i.e., Web server).

Edge Components
WAS 5.0 is the industry's first J2EE application server to bundle edge-of-network functions specifically designed to add value to J2EE applications. The added functionality extends WebSphere's J2EE capabilities out into the network, placing content closer to the end user and enabling a richer Web site experience.

WebSphere version 5.0 Network Deployment introduces the Edge Components CD-ROM. This new offering concentrates the edge-of-network functions - which are typically deployed in a DMZ setting - into a single installable package.

Dispatcher is a general-purpose load balancer for routing and balancing of HTTP(s) requests entering into the enterprise. It is the point of entry into the data center, typically sitting in front of the Web server or proxy tier. Dispatcher monitors many aspects of the resources that are being load-balanced and dynamically adjusts the workload distribution, ensuring that traffic is routed to the most appropriate place as the load within the site changes.

For example, Dispatcher is used to distribute HTTP requests across a cluster of HTTP servers fronting WebSphere Application Servers. Using the Dispatcher technology typically provides near-linear scaling as servers are added to the cluster. In addition, the smart-routing capabilities within Dispatcher optimize workload distribution, using metrics such as CPU, as well as custom advisors sensitive to the actual performance of WebSphere applications.

In addition to the Dispatcher workload management capabilities, WebSphere includes workload management distribution between HTTP servers and Web containers, and EJB clients (including servlets) and EJBs. Version 5 now supports weighted workload distribution in addition to round-robin capabilities.

Caching Proxy provides the required functionality to front-end a cluster of WebSphere Application Servers. SSL termination, authentication, high-speed persistent caching, and intelligent routing functions are combined within a single network hop, thus alleviating the need to deploy multiple proxies that span multiple hops. Integration with Dynacache provides caching of servlet and JSP pages, while integration with Dispatcher technology and WebSphere's J2EE HTTP session provides optimized workload management and routing of stateful WebSphere sessions.

High-Performance
HTTP Session Management

One of the most performance-sensitive aspects of a J2EE application is the management of stateful applications. Application state is typically programmed using the servlet HTTP session APIs and managed using the WAS Session Manager. Managing such sessions in clustered configurations is one of the traditional value propositions of an application server. The WAS Session Manager capabilities allow choices between various degrees of performance and HTTP session data integrity (failover) in clustered environments.

The option with the best performance characteristics operates on a server affinity-based model without failover support. With this model, a front-end server (e.g., Web server/plug-in, caching proxy server, or Dispatcher) uses the JSession token generated by the Session Manager and typically stored in an HTTP cookie header to route requests to the particular server in the cluster that has the requester's session data.

WAS builds upon this model, adding failover support by backing up session data to a relational database. Affinity-based routing matches user requests to the servers containing their session data.When the application modifies the user's session data, an update is sent to the database in order to keep a fresh backup of the session. The backup version is used by another server in the cluster in the unlikely event of a failure in the server containing the session data. Though persisting HTTP session to a database is a very effective failover technique, some customers requested a lower-cost alternative that doesn't require a highly available database.

For this reason, WAS 5.0 offers the option to replicate HTTP session state in a cluster using a memory-to-memory data replication scheme. This scheme does not require a relational database. Instead it uses the Replication domain facility, a JMS-based, publish-and-subscribe model, to flexibly replicate data between servers in a cluster. (Remember, this is the same service that is used to replicate cached data and send cache invalidation events in WAS clusters.)

Within a replication domain, groups of servers are defined as being part of a replication group. A replication group can contain all servers within the cluster, a single "buddy," or some other arbitrary subcollection. An instance of WAS is configured as a replicator, acting as a message broker for the replication domain. Furthermore, a second replicator can be configured for availability purposes. This provides an efficient, flexible, standards-based mechanism for replicating session, without the need for added investment in relational database technologies.

The performance characteristics of persistent session, either shared through database or in-memory, are highly dependent on the size of the HTTP session object. Best practices advise keeping HTTP session objects small for optimum performance. Figure 4 shows the performance results for a cluster test using Ping Session, a servlet with a small HTTP session. In this test, only minimal performance impact is seen using in-memory replication across a five-node cluster.

WebSphere Application Server Enterprise
The WebSphere Application Server Enterprise Edition, available soon, offers programming model extensions to the base and Network Deployment editions of WAS. These extensions offer significant functional, productivity, and performance capabilities. Functional capabilities include process choreography (workflow) and dynamic query. Productivity capabilities include support for business rule beans, work area, and object pooling. This edition also offers opportunities for improving performance, scalability, and efficiency through application profiling, asynchronous beans, and other capabilities. Let's look specifically at the application profiling service and capabilities for startup and asynchronous beans.

Application Profiling
The application profiling service enables deployment-time configuration techniques that enable your application to run more efficiently, with better scalability and performance. You can configure tasks that identify incoming requests, access intents that determine concurrency, and other data-access characteristics. Access intents enable you to specify data-access characteristics on a method-level basis. The application profiling function supports multiple access intents per method, optimizing access to the data for specific callers.

For example, some callers invoke a method with only the intent to read the data, while others can invoke the same method for read with intent to update. Using the application profiling service allows the programmer to develop a single method having different usage-based intents. Using a simple primitive test on a workload that is two-thirds read-intent, one-third read-for-update, the primitive runs three times faster with application profiling. This is compared to the same primitive if all accesses require a pessimistic read for update intent.

Startup and Asynchronous Beans
Enterprise adds a new set of APIs that allow J2EE applications to execute business logic when an application starts and when an application stops normally. For example, a startup bean can be used to warm up a CMP EJB cache by executing finder methods on the required entity beans. Startup beans also support asynchronous operations. The API set enables creation of a work object asynchronous bean to execute the cache warmup operation asynchronously from other work.

Asynchronous (async) beans also provide other parallel-processing mechanisms to an application. For example, writing log records to a database requires time to execute each logging transaction. Instead, the application writes logging records to a vector. Meanwhile, the async bean monitors the vector and writes the log records to the database. An example application using async beans to log such records shows a 2.5x improvement in the rate of logging.

Monitoring and Autonomic Optimization
WAS v5 extends the performance monitoring and tools capabilities of earlier releases. New capabilities include the Performance Advisor Technology Preview, offering tuning and configuration recommendations, as well as new performance monitoring data and interfaces. A brief overview is provided here, and a more detailed article, "Tuning WebSphere 5.0 Using the Performance Advisors" by Srini Rangaswamy and Carolyn Norton, is included in this issue.

New PMI Metrics and JMX Support
The Performance Monitoring Interface (PMI) is extended to provide additional performance data. In addition, all the performance data is now available through JMX interfaces (as well as the original PMI client APIs). For example, the new performance data includes persistent HTTP session size and JDBC read/write times. New performance modules for Dynacache, Workload Management, and the ORB (object request broker) were also added.

The Tivoli Performance Viewer can be used to view the PMI data. For example, an administrator can view the Dynacache cache hit rate on a given servlet or JSP.

Runtime Performance Advisor
A new technology preview provides warnings to the administrator for mistuned pools, queues, and caches. This advisor seamlessly integrates into the WAS runtime and is configured through the admin console. The advisor runs in the background, accesses PMI and configuration data, and exercises a set of tuning best practices. When the advisor detects tuning issues, a warning, along with advice, is generated to the admin console. For example, if the advisor detects a high discard rate on the prepared statement cache, a warning is generated recommending that the administrator increase the cache size.

Tivoli Performance Viewer Advisor
This technology preview integrates performance advice into the Tivoli Performance Viewer (TPV), formerly called Resource Analyzer. In this scenario, a tuning report is generated by the user's request, using the data collected by the TPV. A superset of the runtime advice is applied to the data, and the analysis report includes a set of tuning advice for modifying the settings on pools, queues, and caches.

Because this capability is integrated with the TPV, the reports are generated in real time during load testing or production. In addition, the TPV logging capabilities support running the report offline for analysis.

Request Metrics
WAS 5.0 introduces a new type of performance data, request metrics. While the PMI provides average response times for servlets/JSPs within an application server and values for WAS runtime resources, request-based views of performance data are often valuable. Request metrics provides this data, tracking servlet, EJB, and JDBC entry and exit calls. As a request crosses JVM boundaries, a correlator is passed to allow end-to-end request timing. Request metrics is enabled for specific IP addresses or URLs. The data is logged to an Application Response Measurement (ARM) agent or the WAS logs.

Tools such as Tivoli Monitoring for Transaction Performance (TMTP) provide the ARM agents and produce end-to-end transaction monitoring reports. Request metrics is extremely powerful when enabled for the specific clients generating TMTP synthetic transactions. In this scenario, if a TMTP synthetic transaction shows a response-time spike, TMTP supports detailed transaction drilldown into the ARM data as shown in Figure 5.

Putting It All Together:
Trade3 Performance Benchmark

Trade3 is the third generation of the WebSphere performance benchmark and sample application, a highlight of the WebSphere performance site: www.ibm.com/software/webservers/ appserv/performance.html.

For WAS 5.0, Trade was redesigned to illustrate the significantly expanded programming model and new performance technologies. Trade3 provides a real-world workload, enabling performance research in J2EE 1.3 and Web services, including key WAS performance components and features. Trade3 builds on the fundamental established in Trade2, which is being used for performance research on a wide range of software components and platforms, including WebSphere, DB2, Java, Linux, and more.

Trade3, as shown in Figure 6, includes many of the new J2EE 1.3 and Web services features. New EJB 2.0 capabilities, including CMRs, local interfaces, and EJB Query Language, are exploited. Command-bean and fragment- caching techniques are leveraged. Trade3 also uses JMS and can be run in either synchronous or asynchronous, two-phase commit modes.

Trade3 performance results are collected in many configurations. Figure 7 shows comparisons of Trade3 in both synchronous and asynchronous modes. Two-phase commit performance is improved in version 5, and as you can see, the difference between one-phase commit and two-phase commit for Trade3 is quite small.

Trade3 also provides an excellent example implementation for Dynacache exploitation. The results show greater than 2x performance gains through Dynacache. Additional gains, up to 4x, depending on the workload mix, are obtained if ESI is also used.

Summary
WebSphere Application Server version 5.0 offers exciting new capabilities for developing high-performance, transactive, Web-based applications. Web sites. New functions, such as EJB 2.0 and Dynacache, provide opportunities for significant performance gains. The Edge components, in-memory session replication, and other new capabilities offer flexible, high-performing end-to-end deployment capabilities. These new performance capabilities, combined with new monitoring support, make version 5 the best platform for your Web site.

More Stories By Ruth Willenborg

Ruth Willenborg is a senior technical staff member in IBM's WebSphere Technology Institute working on virtualization. Prior to this assignment, Ruth was manager of the WebSphere performance team responsible for WebSphere Application Server performance analysis, performance benchmarking, and performance tool development. Ruth has over 20 years of experience in software development at IBM. She is co-author of Performance Analysis for Java Web Sites (Addison-Wesley, 2002).

More Stories By Gennaro Cuomo

Gennaro (Jerry) Cuomo is a distinguished engineer at IBM. He has been a core member of the WebSphere development and architecture team since its inception in 1998. Jerry is CTO of the WebSphere Technology Institute, which is responsible for pursuing the next generation of WebSphere technologies.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
bruce 01/13/03 08:43:00 PM EST

I like more about IT information in Java Oracle ......or IBM .............................