The Metro Architecture supports multiple transports, not just HTTP, and the latest Metro Release includes support for SOAP/TCP (Non Assertion Covenant) a protocoal that was designed for intranet use and can provide substantial performance benefits. Besides GFv2 you can also use Metro 1.0 on Apache Tomcat and it should appear in Other Containers (check with your vendor to find when). The latest news, from Paul, is that Noemax now has an Implementation for the Windows Communication Framework (Paul's writeup, Noemax PR) so you can also use in on your Windows box.

Everybody wants performance, but people often fail to define "performance". Most people will think of performance as great benchmark results (GlassFish certainly delivers). Developers would insist on better startup performance. Prashanth has a post entry on the later. It discusses the efforts to bring the startup and shutdown time of GlassFish v2 (single instance or entire cluster) to the best (smallest) possible number. The improvements are broken into modules. Can you guess where the greatest improvement was achieved?

Of course you can expect more improvement from GlasFish v3's kernel architecture with its on-demand module loading.

Recently voted Grizzly committer Naoto TAKAI had a presentation a couple of months ago at RubyKaigi2007. The slide deck is now available here. It mentions Grizzly on Rails (see the "Ruby and jRuby, Mogrel, Goldspike, Grizzly and GlassFish" earlier post), GlassFish v3 and some interesting benchmark numbers against Mongrel, GoldSpike and WEBrick. With the appropriate underlying technology, JRuby on Rails seems to be ready for the enterprise performance-wise. Service providers would be a good judge too.

TransNexus makes software for VoIP operations and billing. Recently, they teamed up with Sun to improve the scalability of their NexSRS VoIP Peering Server. A joint engineering team determined that the use of a single-threaded web server was the primary scalability issue for NexSRS. To address this, they decided to migrate their front-end to GlassFish (and make use of its high-performance Grizzly HTTP Connector).

The results were even better than expected. Not only was scalability improved (76% faster on a four-core system), even single-core performance benefitted (with a 23% improvement). Full details are available in the team's SDN Article: Making Java Technology Faster Than C with LRWP.

Correction: the original web server (Xitami) is not single-threaded, as suggested above. The team did, however, find that it in certain cases it exhibited scalability issues similar to a single-threaded process.

Added: Also see the longer Article at SDN.

Here are a couple of things that change with GlassFish v2 which should trigger better out of the box performance: •  GlassFish v2 supports 64-bit and thus can have a VM with terabytes of heap (see Performance Tuning Guide). •  The GlassFish v2 configuration no longer has an explicit -client switch for better startup time in development mode. This means that Ergonomics will kick in to determine which is best, client or server VM. Read more here.

•  GlassFish v2 also supports Java 6. Performance benefits are almost immediate and free (no code change, no recompile or redeploy). The use of JSR 199 by the JSP compiler is one of the benefits. The SPECjAppServer number is another one.

When Eduardo highlighted the excellent SPECjAppServer 2004 results for GlassFish v1 and PostgreSQL, he speculated that "GlassFish v2 should enable a better number (or similar number on cheaper hardware)." Now, just two weeks later, we have a new SPECjAppServer 2004 result which does use GlassFish v2 (while keeping PostgreSQL 8.2.4 for the DB). Its 813.73 JOPS are about 4.5% better than the 778.14 JOPS obtained in the earlier run with GlassFish v1. And, as Jignesh describes, these new results were obtained using about 33% less hardware. So Eduardo's predication was right on both counts--a better number and cheaper hardware.

Disclaimers: SPEC and the benchmark name SPECjAppServer 2004 are registered trademarks of the Standard Performance Evaluation Corporation. Competitive benchmark results stated above reflect results published on www.spec.org as of 07/23/06. The comparison presented is based on GlassFish v2 run on Sun Fire X4200 (4 chips, 8 cores) - 813.73 SPECjAppServer2004 JOPS@Standard and GlassFish v1 run on Sun Fire X4200 (6 chips, 12 cores) - 778.14 SPECjAppServer2004 JOPS@Standard. For the latest SPECjAppServer 2004 benchmark results, visit http://www.spec.org/.

Picture by Bo Nash.

Want to spice up your webapp with some AJAX widgets? Maybe a sortable table? An expandable tree? Or a controllable progress bar? Then check out Project Woodstock. It provides JSF components which implement all of these widgets and more. Plus, it just got faster. Previously, Woodstock components were sending a lot of large JavaScript files to clients. The team realized this was a problem--pushing up load times and memory consumption. Their solution? Use smaller files, and less of them. So they now compress the JavaScript, avoid using separate template files, and make just one call for each widget's JavaScript (where previously there were too). See Venky's writeup for details.

Having a language run on the JVM using an interpreter is often seen as the first step. This is what both JRuby 1.0 and what JavaFX Script (introduced at JavaOne last May) both do today. Among the leading dynamic and scripting languages, Groovy and JavaScript already have compilers to byte-code. The JRuby team started working on a compiler and so has the JavaFX engineers in close collaboration with the javac experts. Some languages do better than others based on them being dynamic or not (among other things). These first JavaFX Script compiler steps seem very encouraging according to project architect Chris Oliver - "Speed improvement for this particular example is a pretty awesome 54x".

Looking for the relationship with GlassFish? Well you could implement a JavaFX container for GlassFish v3 or use Phobos and the JSR 223 provider for server-side JavaFX!

How can a large project like GlassFish make such brisk strides on performance (1, 2, 3)? Well, for one thing, it certainly doesn't hurt to have backing from a company that has created tools like DTrace.

In his latest blog entry, Paul shows how he used DTrace to identify hot spots in the PostgreSQL JDBC Driver when run on GlassFish. Of course, the same techniques could be applied to any area of GlassFish. So please, feel free to jump in and help with our endless push for top performance.

Added: Also check out this Video Interview of the Dtrace tream.

There is a good thread on memory use on GlassFish at the USERS alias. In the use-case described, the main issue was JSP compilation. Memory consumption is much lower (and compilation is also much faster) in GlassFish v2 using JDK 6 because JSP compilation is done in-memory, using JSR-199 and without forking. Forking can also be avoided in GF v1 and in earlier JDKs with some caveats. Check the mail thread for details.

Picture is a close up on Core Memory. Ah... the good? old days of core and Punched Cards! Have you ever dropped your deck of cards and had to reorder them? That is what those extra columns in the punched card were for :-)...

We're on a bit of a benchmarking kick lately. If you missed it yesterday, be sure to read about the new SPECjAppServer 2004 results for GlassFish v1 and v2. Hint: they're good. Okay, so GlassFish performs well for traditional Java EE technologies. But how well does it handle scripting languages, such as Ruby? Vishnu Gopal decided to find out, benchmarking the same app when deployed on JRuby/Glassfish versus Mongrel/C. Guess what? More good results for GlassFish. In one portion of his summary, for example, Vishnu notes that the GlassFish deployment provides "twice the reply rate in half the benchmark time."

Josh reports another SPECjAppServer 2004 result: 778.14 JOPS@Standard based on GlassFish v1. Although the number is lower than the 883.66 JOPS@Standard we just reported, the submission is interesting in that it is all open source, software (GlassFish, PostgreSQL,...) and hardware (T2000). Playing the leapfrogging game, GlassFish v2 should enable a better number (or similar number on cheaper hardware). Check Josh's writeup for more details.

Disclaimers: SPEC and the benchmark name SPECjAppServer 2004 are registered trademarks of the Standard Performance Evaluation Corporation. Competitive benchmark results stated above reflect results published on www.spec.org as of 07/10/07. The comparison presented is based on GlassFish v1 run on Sun Fire X4200 (6 chips, 12 cores) - 778.14 SPECjAppServer2004 JOPS@Standard and on GlassFish v2 run on Sun Fire T2000 (1 chips, 8 cores) 1.4ghz - 883.66 SPECjAppServer2004 JOPS@Standard. For the latest SPECjAppServer 2004 benchmark results, visit http://www.spec.org/.

Bragging time: 883.66 JOPS@Standard - GlassFish v2 now has the best SPECjAppServer 2004 on T2000; better than BEA's, Oracle's and IBM's. Read Scott's writeup for the details and caveats. The result reflects improvements in many areas including EJBs, JMS, JSP compilation, Servlet connector and container, connection pooling, CMP 2.1 and more. GFv2 has also improved in areas not covered by SPECjAppServer 2004 like Web Services, EJB 3.0, JSF, JPA and others.

As Scott says, benchmarking is a leap-frogging game: tomorrow there may be another T2000 submission that is better than ours, but we have joined the game and we intend to keep hopping in front... And this benchmark is another example that you don't have to choose between Open Source and Enterprise Features: you can have both.

Disclaimers: SPEC and the benchmark name SPECjAppServer 2004 are registered trademarks of the Standard Performance Evaluation Corporation. Sun Fire T2000 (1 chips, 8 cores) 1.4ghz 883.66 SPECjAppServer2004 JOPS@Standard. Competitive benchmark results stated above reflect results published on www.spec.org as of 07/10/06. For the latest SPECjAppServer 2004 benchmark results, visit http://www.spec.org/.

GlassFish partner Caucho is featured in this blog comparing performance of Drupal (the popular content management platform) running on Apache 2+PHP and Caucho's Quercus (100% Java implementation of PHP5+extensions). Scripting on the JVM can offer load-balancing and clustering technologies (courtesy of GlassFish for instance) but it can also let you use the world of enterprise Java APIs. Here it seems to also demonstrate how Java's HotSpot JVM adaptive optimizations kick-in and provide better performance than "native" interpreters on a real-world application.

These tests were conducted all without caching enabled. Interestingly enough, comments suggest using Terracotta (another GlassFish partner) and EHCache, used by Greg Luck in the Wotif.com architecture.

See this post by Ludo to get the Quercus interpreter running on GlassFish.

Proper use of an NIO framework like Grizzly allows you to handle lots of I/O with a minimum number of threads. Still, increasing the allocation of threads for certain tasks can be an important performance-tuning tool. Fortunately, Grizzly makes it easy to customize these settings. In his latest blog entry, Oleksiy shows an example of increasing your Grizzly instance's pool of threads for OP_ACCEPT and OP_READ events.