sorted by: recent | see : popular

Content Tagged with Grizzly + performance

If you've ever had to deal with Java performance tuning, you probably know about a few supported and maybe unsupported JVM tuning flags. Jeanfrancois "Grizzly" Arcand has a set of options for you when it comes to the Grizzly configuration (most are actually startup VM properties).

Here are my top picks (all apply to GlassFish v2):
• HTTP compression
• Comet support
• snooping support (I just like logging options)
• Asynchronous Request Processing
• Resource Consumption Management

As always and similarly to the JVM tuning case, the problem with having many options to choose from is to have methodology and good reasons to try them out. With greater power comes greater responsibility.

On the topic of Grizzly, there's a short article on JavaLobby for its 1.6.1 recent release.

If your site returns full web pages in a second or two, you probably have a bunch of happy users. But if your Ajax-intensive application takes a second or two for each small update to a page, your users may be calling for your head. No problem, you say, because your app handles its Ajax requests very quickly. But what happens when one of your Ajax requests get stuck behind slower non-Ajax requests in your webserver's queue? Lag. (And unruly users, in our example.)

Fortunately, GlassFish provides a solution (with the help of its default network engine--Grizzly). Jean-Francois shows how you can use Grizzly's Resource Consumption Management extension to keep Ajax requests humming along with their own request queue and dedicated handler threads.

Of course, Ajax requests are just one example of traffic which you might want to prioritize with this technique. For more information on this and other advanced functionality in GlassFish, see the " Taste Special Features of Glassfish" lab from this year's JavaOne conference.

Benchmarking writeups seem to attract controversy; let's see how Scott's latest fares... First, a micro-recap: in March, Filip posted a note on NIO scaling up to 16,000 clients; some people read the note as a head-to-head comparison (Tomcat, Jetty, GlassFish) which generated a fair amount of interest [1].

One the key issues when measuring performance is what bechmarking tools you are using. Scott is the GlassFish performance lead and he has an opinion on this... In two recent writeups, he advocated for Faban instead of AB and then showed a Simple use of Faban. In today's blog Scott uses Faban's new Common Driver to test Tomcat and GlassFish against, again, 16,000 users.

GlassFish looks pretty good but you will have to go read his blog to see the details... including his ending remarks:

So does this any of this mean that glassfish is better than tomcat? For some applications, probably. For others, probably not. The real point to take away from this is an understanding of how important it is to understand what you're measuring when you measure performance.... <SNIP> the only realistic benchmark is your own application

Covalent recently published some benchmark results on the scalability of 3 popular Servlet containers: Tomcat 6 using the native APR, Jetty and GlassFish. The results are good for the three, but they favor TC 6 when using a very large number of connections. One danger with performance tests is that is is really hard to make accurate comparisons, despite everybodies' best intentions. For example, inside Sun I've been involved in comparisons between the Web Server and GlassFish and the results are affected by details like how many requests, what response time, what percentage of successful responses, how much memory, what tuning parameters, etc. That is why there are organizations like SPEC and benchmarks like Web2005 and SPECjAppserver (and even those have their own issues).

The Covalent piece is doing a good job in that it is dispelling the myth that Servlet containers do not scale, because it is forcing teams to provide better out of the box performance (Java SE 6 did a great job there) and because I think everybody will be more careful measuring performance. I'd expect improvements on all these fronts in the near future, in the meantime, here are some additional pointers you may want to check out...

• AB Considered Harmful
• Configuring Grizzly for Performance: Part I, Part II
• Comments from Greg W regarding Jetty in that Covalent article.

Regarding the picture, I chose Mark Twain because (a) he popularized the phrase Lies, Damned Lies, and Statistics and (b) he is such a great guy that we should have him somewhere in TheAquarium, but please do note that I am not saying that the covalent blog are lies! :-)