Home > GlassFish, Grizzly > GlassFish Vee(gri)zzly(v3): Unofficial benchmarks results

GlassFish Vee(gri)zzly(v3): Unofficial benchmarks results

We are still working hard on GlassFish v3 and will soon release a new technology preview (JavaOne is coming :-)). What about its performance? As you may know, in v3 we have cleaned up the noise by using a modular approach (thanks Jerome!). In Quebecois (French peoples are probably using some English world to say the same ;-), we say “Faire le Grand Menage”

mathieu 071.jpg

What about Grizzly-In-V3? In v3, the monster is now integrated using its framework module (no http pollution like in v2, just NIO:-)). So when v3 starts, part of its startup logic is done on top of Grizzly (using runtime). Does it make a difference at startup and more important, at runtime? It make a huge one because now, with the modular nature of v3 there is no longer modules that add noise in Grizzly. So let’s benchmark the static resources (.html) performance using Faban (see Scott’s blog about it what is Faban) by using

java -classpath fabandriver.jar:fabancommon.jar -server 
-Xmx1500m -Xms1500m com.sun.faban.driver.ab -c 2000 http://xxx:8080/index.html

This command runs 2000 separate clients (each in its own thread), each of which continually requests index.html with no think time. The common driver reports three pieces of information: the number of requests served per second, the average response time per request, and the 90th percentile for requests: 90% of requests were served with that particular response time or less. Let’s focus on the number of operations per seconds for now by running the test against Grizzly Http 1.0.20, Grizzly Http 1.7.3, v2 and v3:

Grizzly_1.0 Grizzly_1.7 GlassFish_v2 GlassFish_v3
 5739.025    5979.917    5432.300     5882.808

Hey hey v3 is almost as fast as Grizzly 1.7.3. Why? It really because v3 run on top of Grizzly directly, without any noise in between. Now let’s compare the dynamic resource performance using a very simple Servlet

    public void doPost(HttpServletRequest request, HttpServletResponse response){
        PrintWriter wrt = response.getWriter();
        for (int i = 0; i < 1 ; i++) {
            wrt.write("Hello world");

Yes, its a dummy Servlet!

Grizzly_1.7 GlassFish_v2 GlassFish_v3
 3621.600    3256.775      2998.225

v3 is a little slower here……most probably because of the container’s mapping algorithm. What is that? With v3, a tcp/udp port can handle any type of web applications (jruby, groovy, servlet, phobos, etc. (all build on top of Grizzly http :-)). So when a request comes in, v3 inspects and dispatch it to the proper container. That code introduces overhead and I suspect it is part of the regression. But a lot of changes has been made in v3, so I might be wrong…still, I consider the number very impressive as we have now a modular architecture which required a lot of changes.

But wait a minute. Grizzly 1.7 has a Servlet Container? Naaa not a real one. I’m just experimenting a tiny Servlet container, with great help from the Grizzly community. But forget Grizzly for now and look at the number 🙂 The goal for our v3 official release is set: We want to be better than Grizzly, which I’m sure we will :-). We need to improve the Grizzly extension in v3…in case you want to learn how to write such extension, just stop by us at JavaOne!

_uacct = “UA-3111670-1”;


Categories: GlassFish, Grizzly
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: