|
|
||
Jean-Francois Arcand's Blog
«Jersey 0.7 released...with a tiny taste of Grizzly Comet Support |
Main
| Grizzly related talks @ JavaOne 2008 »
GlassFish Vee(gri)zzly(v3): Unofficial benchmarks resultsPosted by jfarcand on April 24, 2008 at 07:37 PM | Comments (4)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"
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 1.7.3.1 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 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: 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 Yes, its a dummy Servlet! 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! technorati: grizzly v3 hk2 glassfish Bookmark blog post: CommentsComments are listed in date ascending order (oldest first) | Post Comment
| ||
|
|