This month a nice mixture of pages have appeared, ranging from chapters of a high performance threading book; to chat sessions on performance; a HotSpot FAQ; and a report on tweaking the internals of the JVM GC spaces; with lots more nice tips as well. And Kirk continues with his roundup, this time adding TheServerSide.com to his visited sites.
Next month, apart from the usual mix of new and old web pages, I'll be pulling together tips on Weblogic as my search agent has thrown up a bunch of these. For those of you who need the pages now, I've listed the URLs below.
All the following page references have their tips extracted below.
All the following page references have their tips extracted below.
These pages will be summarized next month. I've included the URLs here before I've had time to do the usual summary because Weblogic tuning is one of the most frequently requested searches that are directed to the Java Performance Tuning site.
Report on the Insilicon Java coprocessor
I would like to dedicate this month?s column in memory of Dale Earnhardt Sr., who died in a crash at the Daytona 500 while in the pursuit of performance. Dale was a person that had a deep understanding of the systems that he worked with. It was this understanding that made him one of the all time best racecar drivers. We should all be fortunate enough to have as deep an understanding of the systems that we work as he had, even though the results of our failures may not be so tragic.
The web site, www.TheServerSide.com is operated by The Middleware Company. Ed Roman, the founder of The Middleware Company, told me that he has assigned people to maintain and update the information found on the site. The result is a web site rich in information that is both topical and durable. The site supports several discussion groups, including one dedicated to performance.
One of the threads discussed recommendations for stress testing tools. The respondents provided a list that includes Loadrunner (Mercury), JMeter (Apache), Webload (IBM), Web Application Stress (Microsoft), OpenSTA (OpenSTA) and SuperStress of Super (Acelot). To this list, I would add Silk Performer (Segue Software). The question is, which one should you choose? One set of criteria lies in the type and composition of the application that your trying to test. For instance, if you're testing a J2EE application, then you might find it helpful if you can stress the persistence layer in isolation from the web server. Better to determine this up front rather than waiting to find out that your stress-testing tool doesn?t support your particular product/component mix.
There were also two interesting questions regarding threading. The first considered the usefulness of native threading on a system with a single CPU. I suspect that native threading will always be faster than using green threads though I have no facts to support this: I would be interested in hearing from anyone with concrete information.
The second threading discussion considered the number of threads per VM. In theory, one would think that you could run as many threads as the hardware would support. In practice, this seems not to be the case. There appears to be a maximum number of threads that will run in a typical JVM (about 70) and a maximum number of JVMs per CPU (about 2) before you start seeing a performance degradation. This discussion should have further to go.
One excellent piece of advice appeared during a discussion of scalability and availability of an EJB server. The writer advised developers to use a good object to relational mapping tool to start with, then later find your bottlenecks and optimize the RDB access using stored procedures or other techniques. This allows you to reap all of the productivity gains from the mapping tool, while still allowing performance to be addressed using bottleneck discovery. A perfectly sensible approach to take.
Saddle up your VM ?cause it?s gonna be running at a full gallop after reading this months fare.
First, the question of the month, is Java a redundant technology? The answer is, I see nothing in Java that I?ve not seen elsewhere. What makes Java unique is in how it bundles all of these different ideas. For this characteristic, we can only thank the original authors of the language.
Does compiling Java classes to binary native executable increase performance? Without thinking about how this is done, one might think that the answer would be a resounding yes. But responders to this question reported seeing a decrease in performance. The rumor running around the saloon was that at best, one would only see the same performance in the executable as that demonstrated in the Java application. Thus, performance may not be the driving consideration when deciding on whether to compile your Java application to a native executable. One person did point out that they considered executables much easier to deploy.
A summary of a discussion on serialization is that serialization has huge overheads in having to paw through private stuff via the JVM that is normally unavailable, and also with all the reflection it uses. Externalization uses simple method calls: there is no overhead to the calls to your methods, and it normally works out faster.
What can javac do to for you? This started out as a "which code runs faster?" question but quickly turned into an interesting discussion about the state of compilers and what (if any) optimizations that a compiler can provide. In the end, all agreed that the ability of Java compilers to perform optimizations is still in its infancy. And currently javac doesn't optimize much.
What should you use for EJB applications, Session Beans or Entity Beans? What are the performance implications? As is the case whenever you add a layer to your applications architecture, there is a performance penalty to pay. So why add the layer? There are many reasons that are usually centered around design issues. It is generally thought (but not proven) that stateless Session Beans offer better scaling characteristics. The reason for this is that in EJB parlance, stateless Session Beans carry no conversational state. These server entities are shareable amongst several clients so in theory, the server requires fewer resources to manage its clients. The problem is, most services require state, which would appear to limit the usefulness of stateless Session Beans. But, there is an interesting proto-pattern that eliminates this apparent problem. The basis for the pattern is to code your queries in your service layer in stateless Session Beans. Instead of returning the result set to the client, the stateless Session Bean creates an Entity Bean to wrap the return set. A handle to the Entity Bean is returned to the client. The client can pick through the return set at its leisure.
What is more performant than JSP? How about handing rolling your own Sevlets. JSP relies on some one else?s parser so speed will depend upon how good that parser is. But since using JSP presumably speeds development time, the pragmatic approach would be to use JSP until you see that you have a performance issue in this layer.
The discussion on iterating over unchanging collections demonstrated a number of interesting techniques that eliminated the need to cast. But as is often the case, the simple solution was ignored. In this case, the simple solution is to let the collection perform the search. For details see http://java.oreilly.com/news/javaperf_0900.html and http://www.javaworld.com/javaworld/jw-11-2000/jw-1117-optimize.html.
Several questions were asked about which coding technique helps produce a more performant application. A number of people had lots of fun sitting in the Saloon bringing up points and counter points. The answers to each question led to a discussion of the underlying implementation of the VM and dependent classes and in some cases, how this was all tied to the underlying OS/hardware. Thus, the discussions were a lot to fun to read. I?m surprised that they missed the obvious answer to measure a running prototype or test case to find the answer. To be fair, Peter Hagger did offer a test case for one of the questions. One thing to be aware of is that many CPUs don?t directly support floating-point arithmetic. On these machines, math with integers will always be faster.
Optimizing hash functions: generating a perfect hash function (Page last updated January 2001, Added 2001-02-21, Author Jack Shirazi). Tips:
Article on using CachedRowSet, a ResultSet that doesn't need continuous connection to the database (Page last updated February 2001, Added 2001-02-21, Author Taylor G. Cowan). Tips:
Sun community chat session on "Optimizing Java Program Performance" with Peter Haggar. (Page last updated January 2001, Added 2001-02-21, Author Edward Ort). Tips:
importis a compile time function, so has no effect on runtime (i.e. import a.b.*; or import a.b.c; make no difference to runtime performance).
Sun community chat session on "Threading and Concurrency in the Java Platform" with Thomas Christopher and George Thiruvathukal (Page last updated January 2001, Added 2001-02-21, Author Edward Ort). Tips:
Chapter 3 of "High Performance Java Computing : Multi-Threaded and Networked Programming", "Race Conditions and Mutual Exclusion" (Page last updated January 2001, Added 2001-02-21, Authors George Thiruvathukal, Thomas Christopher). Tips:
Chapter 4 of "High Performance Java Computing : Multi-Threaded and Networked Programming", "Monitors" (Page last updated January 2001, Added 2001-02-21, Authors George Thiruvathukal, Thomas Christopher). Tips:
volatilefields can be slower than non-
volatilefields, because the system is forced to store to memory rather than use registers. But they may useful to avoid concurrency problems.
Choosing a J2EE application server, emphasizing the importance of performance issues (Page last updated February 2001, Added 2001-02-21, Author Steve Franklin). Tips:
Article on designing for performance focusing on interfaces (Page last updated January 2001, Added 2001-02-21, Author Brian Goetz). Tips:
Sun engineering report on performance tests of various configurations of the 1.2.2 and 1.3 JVM (Page last updated February 2001, Added 2001-02-21, Author Ed Ort). Tips:
Discussion on JDBC performance (Page last updated August 2000, Added 2001-02-21, Author Swarraj Kulkarni). Tips:
Performance tuning report in German. As I don't speak German, it is difficult for me to comment any further (Page last updated December 2000, Added 2001-02-21, Author Sebastian Ritter). Tips:
iPlanet Web Server guide to servlets, with a section at the end on "Maximizing Servlet Performance". (Page last updated July 2000, Added 2001-02-21, Author ?). Tips:
Article on connection pools (Page last updated September 1999, Added 2001-02-21, Author Hans Bergsten). Tips:
HotSpot FAQ (Page last updated August 2000, Added 2001-02-21, Author ?). Tips: