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.

IBM WebSphere Application Server Total Leadership in SPECjAppServer2004

As noted in the IBM press release, we recently published a SPECjAppServer 2004 result that puts IBM on top of BEA, Oracle, and Sun for the absolutely largest SPECjAppServer 2004 throughput ever achieved. This result comes after we dominated the same competitive crowd on per cpu core performance as I blogged about previously. Both of these results matter. The per cpu core leadership shows application server performance in the most competitive light. The total configuration shows application server scalability in the most competitive light. IBM WebSphere dramatically wins both.

Some numbers from this total leadership publish:

• The result of 14004 JOPS represents roughly 75,000 transactions per second against the DB2 database. Simply impressive.
  
• The closest competitor in total throughput was Oracle at 10519. The IBM result tops that Oracle result by 33%. The IBM result tops the highest Sun result (8439) by 66%. The IBM result tops the highest BEA result (8253) by 70%.
  

Congrats to John Stecher and team. You can read more about the total configuration publish (and John's team) on InfoQ.

SPEC is a non-profit organization that establishes, maintains and endorses standardized benchmarks to measure the performance of the newest generation of high-performance computers. Its membership comprises leading computer hardware and software vendors, universities, and research organizations worldwide. For complete details on benchmark results and the Standard Performance Evaluation Corporation, please see www.spec.org. Competitive claims reflect results published on www.spec.org as of February 18, 2008 when comparing SPECjAppServer2004 JOPS on all published results as well as derived metrics calculated by SPECjAppServer2004 JOPS / Number of Application Server Processor Cores.

WebSphere Beats BEA and Oracle Performance By Over 37%

I wanted to take the time to congratulate some of my performance team members who have worked to prove our performance leadership, displacing both of the current top SPECjAppServer 2004 leaders - BEA and Oracle. You can see this documented in our latest launch press release here.

"A powerful IT infrastructure is also required to support the growing number of transactions across the enterprise, as well as with customers, partners and suppliers. IBM recently beat competitors by 37 percent in an industry benchmark that measures high-volume transaction processing that are typical in today's customer environments. IBM WebSphere Application Server established record-breaking SPECjAppServer2004 benchmark performance and scalability results involved more than 15,500 concurrent clients and produced 1,197.51 SPECjAppServer2004 JOPS@Standard (jAppServer Operations Per Second), which translates into more than 4.3 million business transactions over the course of the benchmark's hour long runtime."

This shows our commitment to standard benchmarking organizations as I described in my last blog post. By leading this benchmark that was designed and approved by all participating SPEC vendors, IBM customers truly benefit from the demonstrated performance leadership.

We chose to lead in a category that matters most to our customers - per core performance. If you look at the result and the number of J2EE server cores and divide it out, we lead Oracle by 37% and smash BEA by 56% with approximately 300 JOPS/core. Comparing per core (CPU) normalized performance is really the best way to compare one application server and hardware stack to another. This demonstrates IBM's leadership of the industry in J2EE performance without question.

This result also shows the combined power of an IBM stack. Specifically, we achieved this by running WebSphere Application Server v6.1 on the IBM 5.0 JVM on AIX 5L V5.3 with an IBM POWER6 p570 server powered by two dual-core IBM® POWER6® 4.7 GHz processors against IBM DB2 Universal Database v9.1 running on a single POWER6-based server.

Congrats again to my team who yet again dominates where it matters - in customer focused standards based benchmarks.

SPEC is a non-profit organization that establishes, maintains and endorses standardized benchmarks to measure the performance of the newest generation of high-performance computers. Its membership comprises leading computer hardware and software vendors, universities, and research organizations worldwide. For complete details on benchmark results and the Standard Performance Evaluation Corporation, please see www.spec.org/. Competitive claims reflect results published on www.spec.org as of October 03, 2007 when comparing SPECjAppServer2004 JOPS@Standard per CPU Core on all published results.