Scott Oaks is the person among others in our great Java performance team behind the excellent and recent SPECjAppServer performance results for GlassFish ([1], [2]). Scott has put out a GlassFish Tuning Primer one-pager. It covers both JVM (throughput collector is suggested as the default choice for large heaps) and application server tuning (acceptor and request-processing threads, JDBC driver statement caching, etc...) and should serve as a good appetizer for our "hundreds of pages of tuning guidelines in our docset".

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.

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.