EJB 3.0 Performance Improvements in WAS V7.0 (up 23%)

EJB 3.0 was actually available for some time on top of WAS V6.1 in the Feature Pack for EJB 3.0, but now it exists in WAS V7.0 as well.  EJB 3.0 in my mind is all about making the developer's life simpler (annotations, test outside of container, etc.) along with giving us a better model for more performant persistence.  You can see all new features added to EJB 3.0 in WAS V7.0 (including performance features) in Kevin's blog post.  Given this is the second major release of EJB 3.0 for WebSphere, performance of EJB 3.0 on WAS is top notch.  You'll also see that we've recently added an implementation using the standard JPA caching functions to allow caching via WebSphere eXtreme Scale (Formally known as WebSphere Extended Deployment Data Grid) which is a distributed in-memory data grid.

In working on persistence performance in WAS V7.0, we used the Apache DayTrader application with some IBM tweaks.  There are two versions of DayTrader of interest (1.2 which uses EJB 2.1 and 2.0 which uses EJB 3.0).  There are other changes as well to move DayTrader 2.0 to Java EE 5, but most don't have deep performance impacts.  Really, the big change from a performance perspective is the implementation of the persistence layer.

The results of all of the new WAS V7.0 features is a very performant EJB 3.0 implementation that outpaces the EJB 2.1 performance by 23% as shown in the below chart.  This is a rather impressive improvement considering the EJB 2.1 implementation has been grooved by years of leading IBM benchmark results in SPECjAppServer.  It is also worth noting that the below chart is EJB 2.1 to EJB 3.0 heads up (actually both are measured on WAS V7.0).  If you are migrating from WAS V6.1 or earlier the percentage improvement would be far greater.

Again, I'm interested in feedback from users who have tried the new engine.

What's so great about WS-Policy?

It's just over a year now since the WS-Policy Specification http://www.w3.org/TR/ws-policy/ moved to RECOMMENDED, and last week WAS 7.0 went GA with support for this spec.

So, exactly what does WS-Policy give us? Conceptually, it's pretty simple: a standard XML format for expressing requirements or capabilities (policies) of a system. To be more precise, it just provides a framework for expressing policies. This is an excellent model for flexibility and extensibility because you can add policies of any 'flavour' within this framework.

A policy flavour or 'domain' might be a proprietary policy - for example, a policy relating to a logging. Alternatively, you can express policies relating to pre-canned standard domains such as WS-SecurityPolicy. So this opens a whole new opportunity: so long as communicating systems understand WS-Policy and the same policy domains, they can exchange information about requirements and capabilities in a standard format. Here are some example uses of this:

• A client could configure itself based on a server's configuration (even if the client and server use different proprietary formats for representing their configurations internally)
  
  
• In a large, heterogeneous environment, a standard policy configuration for many machines could be held in a central repository
  
  
• A service endpoint could advertise its requirements to all its clients in a non-proprietary way

The WS-Policy framework also provides an operator ("All") for combining policies and an operator ("ExactlyOne") for expressing more than one possible option (a policy choice). It may be useful for a service to advertise a choice of requirements, for example, in order to satisfy differing capabilities of a number of clients. This allows for a loose coupling in terms of configuration - because the configuration of an interaction with a service may be flexible and depend on the client.

Finally, WS-Policy provides an algorithm (called intersection) for combining 2 policies together to find an acceptable policy for all parties. So if a client has requirements but also needs to conform to the requirements of the service, you can take the two policies, perform intersection and out pops a policy acceptable to both the client and service.

More about ws-policy support in WAS 7 to follow...

Web Service Performance Improvements in WAS V7.0 (up to 3x)

Two weeks ago, I said I'd be doing a weeklong series of posts on WAS V7.0 performance.  A week late, but here we go.  I guess I can say I delayed until WAS V7.0 was generally available, which it is now (trial download here)!  WAS V7.0 should be available by other supported download methods as well.

There are many impressive areas of performance improvements in WAS V7.0, but I'll start with the one nearest and dearest to my heart - Web Services.  In the past, I talked about web services performance through the years.  I mentioned a possible follow-up blog post on what Feature Pack for Web Services performance.  I never followed up on that (hrm, a theme in my slow blogging), but now that the same code is available in WAS V7.0, I will.  In fact, we've made even more improvements to web services performance in WAS V7.0 that would truly make the "performance through the years" chart from my previous blog post much more impressive.

WAS V6.1 supports the J2EE 1.4 JAX-RPC web service programming model.  Last year, we added Java EE 5 support for the JAX-WS web service programming model (expanded functionality, standards support, easier programming model, and enhanced management support for services) through the Feature Pack for Web Services.  While WAS V7.0 continues support of both the JAX-RPC and JAX-WS programming models so that existing JAX-RPC web services applications deployed on previous versions of WebSphere will run on V7 unmodified, the development and performance resources were almost exclusively dedicated to the JAX-WS work.  We encourage customers to move to this new programming model to take advantage of the new features as well as the significant performance gains.  Many customers I know of have moved to the Feature Pack for Web Services already, but now that it's natively supported in WAS V7.0, I expect even more customers to make a move from JAX-RPC to JAX-WS.

The chart below compares WAS V6.1 JAX-RPC performance to WAS V7.0 JAX-WS performance.  JAX-WS web services significantly outperform JAX-RPC web services for all message payload sizes shown.  For a 3k(input)/3k(output) message size, JAX-WS achieves a 70% higher throughput and for 10k/10k message size JAX-WS achieves over 2x higher performance.  For 10k/3k, 10k/10k, 100k/100k JAX-WS achieves over 3x/2.5x/2.5x higher performance, respectively.

There are many reasons for these performance gains, but the most significant one is the optimized data binding using JAXB in JAX-WS.  JAXB provides JAX-WS the framework to unmarshal XML documents into Java objects or marshal Java objects into XML.  We have done very impressive optimizations in our JAXB implementation to achieve these performance gains, well beyond what most JAXB implementations can do with StAX or SAX.  Getting high performance XML parsing combined with JAXB's full support for XML Schema is an impressive accomplishment.

Some things that matter to you specifically:  This is a primitive benchmark as it only measures web services performance (no business logic).  Therefore, your application using web services will not go 2-3 times faster just by switching to JAX-WS and JAXB, but it should markedly improve.  Specifically the additional latency involved in exposing business logic to web services and XML should go down by 1/2-2/3, which in many scenarios is substantial.  Also, even though you can handle XML yourself in JAX-WS by getting the data as a stream or DOM, it's best if you use JAXB as you'll get the most performance benefit of our optimizations.

I'm interested in feedback from users that have tried the new engine.

Need help with WebSphere scripting..?

In WebSphere 7.0 the main focus from administration perspective is on making things easy to manage in a complex environment. Over next few days I will be sharing my views on various such features like highly scalable management topology, business level application, properties file based configuration etc. I think one of the most important features for administrators in WebSphere 7.0 is the new jython script library.

WebSphere scripting is a detailed subject with lots of capability. I have had administrators often ask me - "I am new to WebSphere .. or I used to use console UI but now we want to automate all of our WebSphere administration. Where do I begin? .. or I know my script command works but how can I confirm that it covers all the scenarios or topologies?". The jython editor in Rational Application Developer goes a long way in boosting productivity of WebSphere script developers. The script library that we ship with WebSphere 7.0 is another good source for administrators trying to automate WebSphere administration tasks. The script library contains a number of good scripts for common administrative functions such as -

• Application management: install, uninstall, update, start, stop
• Server/Cluster management: create, delete, update, start, stop server or cluster. Need a quick example to set a server JVM property or trace specification? You will find it in there.
• Resource Manipulation: create/manipulate resources for JDBC, J2C, JMS and so on
• Security configuration: manipulate authorization for users and groups
  

You can call these scripts from your script code or just copy them and modify any way you want. I encourage you to take a look at these scripts to see how they check preconditions before executing commands or perform exception handling etc. Automation is a big factor in WebSphere administration and we are striving hard to make it easier for our administrators.

- Ajay

To run WebSphere v7, first you have to install ...

Basically "Install" is one of those things people want to be able to ignore - they want it just work and be done with it. So, a major part of v7 install work was to keep everything working the same way and as well as v6.1 installs. We must have succeeded since most users may not notice any obvious difference, although under the covers there are several improvements. There are minor GUI changes to make the various installers (WebSphere, HTTP Server, plugins, client, Proxy Server, FeaturePacks, etc) more similar to each other in appearance and behavior.

Linux/AIX/HPUX/Solaris non-root installs are fully supported, which sounds fairly straight forward but had huge internal impacts. As well, installation performance has been increased such that the significantly enhanced v7 servers still install in the same time as the previous v6.1 servers. Keeping install performance (time) the same while laying down several hundred more megabytes was a challenge, but the team worked to find many places where a few seconds here-and-there could be shaved, and the net result is almost identical time for v7 versus v6.1 installs.

So, the "Install" should have "no surprises" - the real changes are WebSphere v7 itself. As soon as you can get it, give it a spin ...

Have it your way

One of the trends I've been seeing a lot of lately in the industry is a movement towards something I would call "build to order". Given that this is something that we see in a number of industries (restaraunt meal preparation, automobile options, custom motorcycles, etc.), it seems no surprise to me that the computing industry wouldn't also be affected by this. We all want to have it our way, not what is provided for the mass of humanity. In a highly competitive industry, having custom solutions can provide differentiation which may be crucial in a value chain. On the other hand, it can also hinder your ability to adapt if it means creating a new custom solution for every customer.

WebSphere Application Server (WAS) has been on a path for some time now to enable custom solutions. Starting way back with WAS 6.0 (2004), astute system administrators may have noticed that we have started packaging the WebSphere runtime in OSGi bundles located in the "plugins" directory. What OSGi does is allow for some separation of concerns and decoupled code selection, as well dynamic hook points for integration. This, in turn, allows WAS to be configured in a variety of ways that were difficult or impossible in the past.

Take, for example, the use of open source. When used in an application, it can help the application developer achieve their goals in a rapid way by utilizing the efforts of the open source community rather than reinventing similar function. The same could also be said for the server. If you are wondering about how much open source gets used in creating WAS, try taking a look at the /lafiles/notices file. Having all this open source in the server can be both good and bad. If an application developer wants to take advantage of it, it's there. However, if it's not the version of the open source the developer wants to use, it can be bad. This is where OSGi's separation of concern can come into play. OSGi modules allow for restricted views of the code in the OSGi bundle. Use of OSGi bundles allows servers to take advantage of open source without actually exposing it to applications. The server's use of open source will not interfere with application's that bundle and use open source. WAS version 7 has refactored much of its runtime to hide open source intended to be used by the runtime. This is coupled with new managed shared libraries, isolated shared library classloaders, and the repackaging of open source into the /optionalLibraries directory to make it much easier to deploy and configure applications. Applications can either bundle the open source they want, or manage multiple shared lib versions of it used by applications in WAS version 7.

Another area where OSGi has helped is in server footprint. OSGi allows for dynamic code use and enables the possibility of load on first use. What this means is that you now have the option of configuring the server to use only as much of the runtime as is necessary. OSGi alone can't do this, so a fair amount of work has gone into getting the WAS version 7 runtime enabled for dynamic provisioning, some of which can be automated, and some of which must be manually configured. One of the most frequent questions I get around this is how much will it reduce the server footprint. As with all performance related questions, it will depend on the scenario. I will say that we've only touched the tip the iceberg for possibilities here and I think we've got a good head start on the competition. For more details, stay tuned to hear from Andrew Spyker as he posts updates on WAS performance.

WebSphere Application Server V7.0 Messaging

WebSphere Application Server V7.0 contains a number of enhancements to the service integration technology (SIBus) that make it easier to set up and manage, improve performance and provide greater flexibility for messaging applications.

To help you discover the new features contained in V7.0 we'll be blogging them at WebSphere and Messaging over the coming weeks.

Here's a taster of some of the new features of WAS V7.0 that we'll cover:

• Consumability improvements
  • New console wizards to make configuration easier
  • Improved facilities for monitoring and control
• Improved integration with WebSphere MQ
  • Using WMQ directly from WAS via the new JCA 1.5 Resource Adapter
  • Using WMQ via the SIBus - increased platform coverage and additional facilities
• Clustering improvements
  • Better workload balancing
  • New options for message routing and visibility
  • Response routing within a cluster
  • Additional options for MDB activations
• Security changes
• Connectivity from client environments and from servers outside the cell
• Performance improvements

All of the new features of WAS V7.0 are described in the InfoCenter but if you'd like to hear about them from a different perspective and have the opportinuty to discuss them, then please pay a visit to the WebSphere and Messaging blog.

Graham

WebSphere and Java Persistence

With the recent announcement of WebSphere v7, we are now on our second release of providing a Java Persistence API (JPA) solution for our WebSphere customers. We first delivered JPA as part of the WebSphere v6.1 Feature Pack for EJB 3.0. Built on top of the Apache OpenJPA project, not only is the WebSphere JPA solution CTS compliant, but it also contains several WebSphere value-add extensions.

In WebSphere v7, the WebSphere JPA solution provides the following features beyond the base JPA specification (those marked with an asterisk were provided in the Feature Pack for EJB 3.0 as well):

• Performance Improvements
• DB2 pureQuery (Static SQL) integration
• ObjectGrid Cache plugin
• SQL Statement Batching *
• DB2 Select Statement Optimizations *
• Consumability Improvements
• Access Intent support
• XML Column Mapping *
• DB2Diagnosable exception processing *
• Enhanced tracing using AspectJ *
• Database generated version IDs *
• Command scripting (.bat/.sh) *
• Globalization
• NLS Message Files *

More information on these features can be found in the InfoCenter. Due to the numerous requests we receive concerning the WebSphere JPA solution, we have also decided to create a blog devoted to WebSphere and Java Persistence. Please visit and share your comments as we continue to populate this avenue for sharing information.

New Dynacache Features in WebSphere 7 - Part 1

Are you looking for WebSphere Application Server V7.0 new features? If so, look here. If you are looking for new features relating to Dynacache, continue reading.

I am excited about the new Dynacache heap management feature in WAS 7. The primary motivation for introducing this feature is for serviceability. Many times customers trip up on themselves by caching too much stuff. I have lost count of the number of critical situations where I have been hauled from the bed, by some customer critical situation where the server was down due to an OOM error. It is extremely important to size the cache well. Unfortunately this is not an easy thing to do and pre-production stress testing in some cases does not simulate real world traffic which leads to an underutilized cache and thus false confidence in the capacity utilization of the cache.

This is not an easy problem to solve. There is no sizeof operator in Java which will tell us the size of an object in the JVM heap. Therefore we have to use all sorts of smarts, trickery and some help from the application developer to determine the total amount of memory on the JVM heap taken up by the cache. All earlier techniques to determine cache size rely on serializing the cached objects and metadata because that is the only way to accurately determine the size of the objects. In WebSphere 7 we have taken a much light weight approach which does not rely on serialization to determine cache heap size.

Most application servers allow cache size to be controlled by no.of entries. We are taking cache size management to the next level in WebSphere Application Server 7.

What exactly does Dynacache provide ?
WAS Dynacache component will provide an ability to constrain the cache in terms of the JVM heap. In addition to specifying the cache size in MB, Dynacache will also allow customers to set a high water mark and a low water mark for the cache heap consumed. Once cache heap memory reaches the high water mark, dynacache will either discard or evict the least recently used items to disk, till the cache is brought down to the low water mark. This functionality of limiting the cache in terms of the JVM heap will be available if the objects put into the cache that implement the com.ibm.websphere.cache.Sizeable interface. When servlet caching is enabled, all the cached JSP and servlet responses will be Sizeable. This interface will have one method which will return the size of the Object in bytes put into the cache. Dynacache will use the Sizeable interface to estimate the heap size of the cache. This feature will be OFF by default. A customer will have to explicitly enable and set cache limits and watermarks.

How to enable this feature ?

On the Dynacache service panel, WebSphere exposes the Dynamic Cache object cache service and Dynamic Cache servlet cache service. The Dynamic object cache service is always started at server start up. The Dynamic servlet cache service is started when the servlet caching is enabled in WebContainer panel. There is now a checkbox for Memory Cache Size which will control the memory cache size with high/low threshold. In addition to specifying the size the customer can also specify a range for the heap by setting threshold limits. The Servlet and Object Cache instance under the Resources -> Cache Instances have also include the Memory Cache Size control feature.

WebSphere Application Server Version 7.0 Performance Highlights

We recently announced WebSphere Application Server V7.0. Over the next week, I will be sharing some of the performance highlights of our teams' work improving existing usage scenarios as well as performance grooving of new V7.0 features. Here are some of the areas I plan to discuss.  Let me know if you'd like to see other areas and I'll work to include them as well.

• General Java EE
• Web Services including JAX-WS and WS-* standards support
• Persistence including EJB3 and JPA
• Startup Time and Memory Footprint
• Security including Java SE, Admininstration, Java EE, and new features
• Java SE Performance
• Hardware exploitation (64-bit, Multicore, Virtualization)
• Support for SIP based communication in our convergence sevlet container

Documentation Approach about Web Services for WebSphere

As part of the approach for delivering Web Services as part of WebSphere Application Server, the web services team is experimenting with multiple approaches for providing information to our end users. In addition to updating the Information Center about new features about web services, we are looking at alternative approaches to getting information into our hands of our end users. One approach is using developerWorks articles. For the Feature Pack for Web Services that we delivered on top of WebSphere Application Server v6.1, we worked with the developerWorks editors and put together a list of articles, which discuss the technology. As part of that work, we listed comparisons between JAX-RPC and JAX-WS (part1, part2, part3, part4, and part5) as well as the JAX-WS technology itself (via dispatch clients and JAX-WS annotations). For interoperability between the Feature Pack for Web Services and other vendors, we offer the following articles for interoperability with Microsoft (part1 and part2) and Apache Axis2. Other miscellaneous articles include a discussion of WS-I’s Supply Chain Sample Application built on the Feature Pack and troubleshooting web services applications in the Feature Pack and we have more in the pipeline.

Lastly, another approach is the usage of Redbooks. Members of our development organization participated with other IBM folks to help produce a Feature Pack for Web Services Redbook. These are all meant to be ways to compliment our existing Information Center and provide specific useful scenarios in a more end-to-end fashion to help our developers get on board.

I hope you like the approach and would be interested in hearing your feedback.