JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

JavaPerformanceTuning.com has now been available for two years. Even when the site opened, we immediately provided the most comprehensive set of information related to Java performance available anywhere on the web. Then, we opened with over five hundred performance tips at the end of October 2000. Now we're coming up to the three thousand tips mark. Tips cover everything from specification to deployment, design to profiling, volatile to EJB, J2ME to J2EE, JNI, graphics, audio, and much, much more.

Apart from the tips we also provide the most comprehensive list of Java performance resources on the web. The number of people coming to the site has steadily increased month on month, and the rate of increase seems to be growing. Almost every query for performance information in Java discussion groups and on Usenet includes a reference to JavaPerformanceTuning.com. All of that and we give you the relevant Java performance news too.

This two year-old toddler, born after the excesses of the dot-bomb were unravelling, is growing fast and healthily. We hope to provide comprehensive Java performance information for many years to come. Happy Birthday JavaPerformanceTuning.com.

A note from this newsletter's sponsor

This month we continue to find many articles discussing features available from the NIO library. There are also many articles covering various aspects of J2EE (JDBC, EJB, Scaling, Clustering, Sessions and Servlets), as well as articles on ThreadLocal, Swing, animation, profiling, optimizing and OS-level monitoring.

Martin Fowler's article "Yet Another Optimization Article" is worth singling out. Martin often comes up with real gem quotes, and this time is no exception. Here are a couple of those gems:

If you make an optimization and don?t measure to confirm the performance increase, all you know for certain is that you?ve made your code harder to read.

After upgrading your compiler or VM, the optimization you did six months ago could be your bottleneck today.

Lovely .sig material. Kirk and Javva are also here with their excellent contributions; we have news, new tips categories, and new tool reports. Welcome, dive in and enjoy.

A note from this newsletter's sponsor

New Tips Categories

• JMS performance tips
• JDBC PreparedStatement tips

Tool Reports

• The J-Sprint profiler, a cheap but fully featured Java profiler
• Steve Souza has updated his Java monitor (JAMon) to open source, and added servlet filters and more examples

News

Java performance tuning related news.

• Joakim Dahlstedt, one of the originators of the JRockit JVM, discusses Java's performance advantages
• Alan Williamson discusses AWT and Swing performance shortcomings, and available alternatives
• Pramati posts SPECjAppServer2001 benchmarks
• Intel licenses Precise's Indepth J2EE monitor for Intel's VTune enterprise analyzer
• Isocra announces the release of Livestore, a transparent JDBC data cache
• JRockit JVM focuses on performance
• GemStone CMP Accelerator now works on JBoss
• GemStone GemFire real-time shared-memory cache version 1.0 released
• Altaworks talks about the need for intelligent performance analysis of J2EE systems

A note from this newsletter's sponsor

Books

• Linux Performance Tuning and Capacity Planning, by Jason Fink, Matthew Sherer, Kurt Wall

Tools

• Light-weight XML Encoding Library
• Isocra's Livestore, a transparent JDBC data cache
• HPjtune for analyzing garbage collection from the -verbosegc output

Recent Articles

• WebSphere performance tuning (Gennaro (Jerry) Cuomo Srini Rangaswamy/IBM)
• WebSphere HTTP session best practices (David Draeger/IBM)
• Optimization (Martin Fowler/martinfowler.com)
• Web server monitoring (Freshwater.com/Freshwater.com)
• Session persistence performance (Saurabh Dixit & Srikant Subramaniam/WeblogicDevelopersJournal)
• Sun community chat on NIO (Edward Ort/Sun)
• FileChannel objects background information (Richard Baldwin/Earthweb)
• Clustering J2EE (Ashok Banerjee, Ganesh Kondal & Sunil Kunisetty/JavaDevelopersJournal)
• JDBC drivers (Heinz Kabutz/DevX)
• Scaling J2EE (Mikhail Skorik/JavaDevelopersJournal)
• File Locking (John Zukowski/Sun)
• NIO (Ron Hitchens/OnJava)
• The Timer service (Richard Monson-Haefel/TheServerSide)
• JDBC tips (William Crawford/Oracle)
• Smooth animation/sprite engine requirements (Chris Preimesberger/DevX)
• Swing multi-threading (Guruprasad H.N./IBM)
• Row level locking (Nicholas Whitehead/ITtoolbox)
• Chapter 3, "Popular Unix Performance-Monitoring Tools for Linux" from "Linux Performance Tuning and Capacity Planning" (Jason Fink/InformIT)

Older Articles

• Performance tuning with OptimizeIt (Jay Campan & Eric Muller/Borland)
• ThreadLocal (Brian Goetz/IBM)

Jack Shirazi

Kirk's roundup

My apologies, Kirk's roundup is unexpectedly unavailable this month.

Kirk Pepperdine.

Javva The Hutt

I started out in a Unix environment. For sure it took a while to get used to the tools and utilities, and understand what I was doing. But by the time I started touching PCs, I was comfortable in Unix. MS-DOS seemed brain dead in comparison. Windows has always been like a straight-jacket. In Unix I can fly my own plane anywhere; in Windows I can get on at stop A and get off at stop B, but if I want to go anywhere else I need to build an aeroplane to do it.

My brother-in-law started in MS-DOS. Windows, every version, was sooo much better. More and more things that you could do. He's had to work in Unix environments every now and then, and always moans "why do they have to make it so complicated?". He's right of course. I'm still more comfortable in Unix, and if I need to tweak a system to do things just right, then Unix is way way better for me. But Windows is much more user-friendly. For 90% of what most computer users want to do, Windows is easier to operate. (Hence the emphasis on nice Linux front-ends).

What is this little ramble about? Well I was reading Paul Prescod's rant about keeping web services simple, and came across this line:

it's debatable whether scalable, robust, fault-tolerant Web service construction can be made as easy as clicking buttons on a dialog box.

He was talking about Visual Studio.NET generating web services, but the issue is wider. It's been my experience that performance and scalability lie in the region where you cannot provide a simple interface that will optimize the system. Whether talking about Web Services, JVMs, or Windows/Unix, you need to be able to get under the surface, see what's happening, tweak things that the system designers didn't think about, and generally play process-God if you want to get the maximum out of the system. Prescod goes on to say

Networked applications must intrinsically deal with many issues that don't affect local programs: latency, race conditions, topology changes, network outages, obsolete client and server software, denial of service attacks, and so forth. The dialog boxes don't offer any strategies to deal with these problems. When today's Web services are deployed in the real world, I expect we'll find that ignoring these issues will have serious consequences for the reliability of our services.

I suspect we are going to see a lot of non-scalable web services for a long time.

Diary of a Hutt

September 18. It's always so difficult to throw yourself back into work after a long relaxing holiday. So many meetings, smail piled up, cluttered up inbox, etc. I believe it will take the whole week before I'm even close to be able to pick up where I left off. Weevil didn't seem happy to hear how much has piled up for me. For some reason, he seems to be desperate to hand off my project back to me. Actually I sneaked a look. He's way behind schedule, and I'm enjoying see him stew. HasntGotAClue fully understands my backed-up workload, and is comfortable with Weevil carrying on this week. I've scheduled a progress report from Weevil for tomorrow. Made sure HasntGotAClue was free, sent the memo to Weevil, then added HasntGotAClue to the attendee list.

September 19. Weevil was taken sick, just after HasntGotAClue joined the meeting. Shame really. Weevil had just started berating me for the ridiculous time schedule I'd set up for the project, and was just reaching full-bodied language. Then HasntGotAClue came into the room, and I was just telling him how he hadn't missed anything and that Weevil was just about to start his report. Weevil seemed to turn red then white, and all but collapsed. Said he couldn't breathe properly. Poor guy. Overworked if you ask me.

September 25. Well Weevil and I have agreed that the schedule was a little too optimistic. Actually he was desperate to agree anything as long as I would take the project off his hands. So our joint recommendation to HasntGotAClue is that the project implementaion time should be tripled. Weevil also agreed to state essentially that most of his work needed to be written-off. Incomplete due to timing pressures. Actually I can use a good proportion of it, but I couldn't miss the opportunity to put the screw in. HasntGotAClue wasn't too happy, but it is not a unique situation having to convert a project to a "prototype" because the requirements were incorrectly assessed. He demoted Weevil though. Decided that I needed an alternative liaison while Weevil went for some training to get him "up to spec". If I was Weevil, I'd be polishing up that CV again. How many departments can he be under spec for?

October 2. So now, I've got essentially to the end of the year to implement my performance management integration with QA. With Weevil's stuff it shouldn't take more than a month maximum. I think I'll be coming in a little ahead of schedule. Not too much, of course, I don't want my projections to be off, just ahead enough to look good. Always start performance tuning by giving your own performance a little tuning. I think I'll make that my motto! And I've done the classic tune: set expectations correctly and you can always beat them.

BCNU

Javva The Hutt.

Tips

http://www-3.ibm.com/software/webservers/appserv/doc/v40/ws_40_tuning.pdf
WebSphere performance tuning (Page last updated August 2002, Added 2002-10-30, Author Gennaro (Jerry) Cuomo Srini Rangaswamy, Publisher IBM). Tips:

• There is no magic configuration in which the systm will provide best performance. It has to be configured and tuned by considering the components involved in an application, incoming traffic (load) and required throughput.
• Understanding object usage and tuning the JVM heap size is an important element of overall performance.
• A size restricted queue (closed queue) allows system resources to be more tightly managed than an open queue.
• The network provides a front-end queue. A server should be configured to use the network queue as its bottleneck, i.e. only accept a request from the network when there are sufficient resources to process the request. This reduces the load on an app server. However, sufficient requests should be accepted to ensure that the app server is working at maximum capacity, i.e. try not to let a component sit idle while there are still requests that can be accepted even if other components are fully worked.
• Try to balance the workload of the various components.
• Throughput has three zones: light load (spare capacity is available, the system can accept further users with no response-time degradation); heavy load (no spare capacity, system working at maximum potential, throughput is constant and extra users can only be served by degrading response times of all users); buckle zone (a bottleneck appears which causes the system to run below maximum potential, both througput and response times decrease). [Paper shows a nice throughput curve giving recommended scaling behavior for an server]. The point where light load becomes heavy load is the saturatiuon point, and you should aim to tune the application until this corresponds to the target user concurrency level.
• The desirable target bottleneck is the CPU, i.e. a server should be tuned until the CPU is the remaining bottleneck. Adding CPUs is a simple remedy to this.
• Use connection pools and cached prepared statements for database access.
• Ensure that the application is not leaking or over-utilizing objects; and that your Java heap parameters are set to handle your object utilization.
• Object memory management is particularly important for server applications. Typically garbage collection could take between 5% and 20% of the server execution time. Garbage collection statistics provide a useful monitor to determine the server's "health". Use the verbosegc flag to collect basic GC statistics.
• GC statistics to monitor are: total time spent in GC (target less than 15% of execution time); average time per GC; average memory collected per GC; average objects collected per GC.
• For long lived server processes it is particularly important to eliminate memory leaks (references retained to objects and never released).
• Use -ms and -mx to tune the JVM heap. Bigger means more space but GC takes longer. Use the GC statistics to determine the optimal setting, i.e the setting which provides the minimum average overhead from GC. After 1.2, set the -mx and -ms to be different to give the garbage collector a chance to adapt to the application working set size.
• The ability to reload classes is typically achieved by testing a filesystem timestamp. This check should be done at set intermediate periods, and not on every request as the filesystem check is an expensive operation.
• Use the most efficient transaction isolation level

http://www7b.boulder.ibm.com/wsdd/library/techarticles/0209_draeger/draeger.html
WebSphere HTTP session best practices (Page last updated August 2002, Added 2002-10-30, Author David Draeger, Publisher IBM). Tips:

• Using one database row for a session is more efficient than using multiple rows.
• Using in-memory writable caches with periodic data writes of changes to the database is recommended for maximum efficiency.
• Don't store large Object graphs in HttpSession. Keep the amount of data stored in the session as small as possible.
• Release HttpSessions when finished.
• Create a session before accessing multi-framed pages that utilize JSPs.
• Use <% @ page session="false" %> to turn off the automatic session creation from the JSPs that won't update the session. Use <%HttpSession session = javax.servlet.http.HttpServletRequest.getSession(false);%> to get the already existing session.
• Update session data using only one frame.
• Do not use multi-framed JSPs where the frames point to different Web applications.
• Use a dedicated database for the session database to avoid contention for JDBC connections and get better database performance.

http://www.martinfowler.com/articles/yetOptimization.pdf
Optimization (Page last updated September 2002, Added 2002-10-30, Author Martin Fowler, Publisher martinfowler.com). Tips:

• It is difficult to make decisions about performance from just looking at the design. You have to actually run the code and measure performance using a profiler.
• Use automated test suites which simulate actual conditions.
• Multiuser systems have very different bottlenecks from single user systems, often focused around transaction interactions.
• Once you?ve found your bottlenecks, you have two choices: speed up the slow things or do the slow things less often.
• It?s much easier to optimize cohesive, loosely coupled modules.
• If you make an optimization and don?t measure to confirm the performance increase, all you know for certain is that you?ve made your code harder to read.
• After upgrading your compiler or VM, the optimization you did six months ago could be your bottleneck today.
• Most performance issues are resolved by profiling and optimizing code. But the effects of architectural issues need to be measured early on.
• Remote calls are orders of magnitude slower than in-process calls, so it?s important to minimize them.
• Performance is not an absolute. Getting a program to run faster costs money, and it?s a business decision whether to invest in a quicker program.

http://www.messageq.com/systems_management/freshwater_1a.html
Web server monitoring (Page last updated September 2002, Added 2002-10-30, Author Freshwater.com, Publisher Freshwater.com). Tips:

• A Web site that fails to deliver its content in a timely manner will cause visitors to quickly lose interest.
• Monitors check components on a periodic basis, frequently enough to catch failures in a timely manner, but not so frequently as to significantly impact system resources such as CPU or network bandwidth.
• Common monitors include: Ping Monitor (Tests whether a machine is reachable over the network); Process Monitor (Ensures that a process is still active); Disk Space Monitor (Measures the percentage of disk used to prevent full disks); CPU Monitor (Measures the utilization of the CPU to flag chronic overloading).

http://community.borland.com/article/images/28892/cpu_performance_essentials.pdf
Performance tuning with OptimizeIt (Page last updated March 2002, Added 2002-10-30, Author Jay Campan & Eric Muller, Publisher Borland). Tips:

• Regular checking and testing of small modules of code from the earliest stage of code creation throughout the development process, into QA testing, and beyond. by the principal author is a proven way to assure that the Java applications produced will be fast, reliable, and scalable.
• Three crucial performance issues for Java programs are: Java memory leaks, speed bottlenecks due to poor CPU utilization, and excessive use of temporary objects.
• Sampling (taking periodic snapshots of the runtime stack) is appropriate for profiling long running sessions; Instrumentation (instrumenting the code to identify the time cost for each method) is appropriate for profiling short sessions.
• [Paper works through an example of tuning a servlet using OptimizeIt].
• Cache objects rather than re-generating them if they will be reused.
• Use conditional tests to avoid executing statements that are unnecessary.
• equalsIgnoreCase() is more efficient than the combination of toLowerCase() and equals().
• If repeatedly accessing an XML file, SAX must parse the file each time, but DOM can create an in-memoy representation which is more efficient for repeated access.

http://www-106.ibm.com/developerworks/library/j-threads3.html
ThreadLocal (Page last updated October 2001, Added 2002-10-30, Author Brian Goetz, Publisher IBM). Tips:

• ThreadLocals provide you an alternative to resource pooling which avoids synchronized access of the resource, so improving scalability.
• ThreadLocal performance has dramatically improved over versions: the 1.2 implementation is synchronized and so didn't scale; the 1.3 implementation is faster than 1.2 but uses Thread.currentThread() which slows it; 1.4 is finally fast enough to make using ThreadLocals efficient for resource management.

http://www.sys-con.com/weblogic/article.cfm?id=163
Session persistence performance (Page last updated October 2002, Added 2002-10-30, Author Saurabh Dixit & Srikant Subramaniam, Publisher WeblogicDevelopersJournal). Tips:

• Memory based session mechanisms are the fastest if seralization of the session data can be avoided.
• Cookie based session mechanisms are efficient when you don't need to store large amounts of data in the session.
• Database based session mechanisms are slow but fault tolerant.
• File persistence is the slowest mechanism for managing sessions.

http://developer.java.sun.com/developer/community/chat/JavaLive/2002/jl0919.html
Sun community chat on NIO (Page last updated September 2002, Added 2002-10-30, Author Edward Ort, Publisher Sun). Tips:

• The main advantage of socket channels is that you can do non-blocking [multiplexed] I/O.
• Socket channels can transfer data more efficiently if you use direct buffers for reads and writes.
• Memory-mapped buffers are only reclaimed when they're GC'ed. You may need to explicitly call System.gc() to reclaim space from memory mapped files that you have finished with.
• The "optimal" size for writing to a socket channel depends entirely upon the size of the channel's send buffer. The default size varies from OS to OS; you can use the {get,set} SendBufferSize methods in java.net.Socket to view and change the buffer size.
• Mark Reinhold's general rule for direct buffers is that you shouldn't use them at all unless you can demonstrate a clear performance improvement.
• NIO improves graphical application performance by memory mapping the video card memory into the Java application, allowing very fast updates to the screen bits.
• Memory mapping files under 10K is not recommended. Memory mapping really big files may stress the virtual memory system of the operating system. In such cases consider memory mapping only sections of the file if possible.

http://softwaredev.earthweb.com/java/article/0,,12082_1473151,00.html
FileChannel objects background information (Page last updated September 2002, Added 2002-10-30, Author Richard Baldwin, Publisher Earthweb). Tips:

• The FileChannel.map() maps region of a file directly into memory. For large files this is often much more efficient than invoking the usual read or write methods."
• The FileChannel.transferFrom() and FileChannel.transferTo methods can transfer data file to some other channel, and vice versa in a way that can be optimized by many operating systems into a very fast transfer directly to or from the filesystem cache.

http://www.sys-con.com/java/article.cfm?id=1662
Clustering J2EE (Page last updated October 2002, Added 2002-10-30, Authors Ashok Banerjee, Ganesh Kondal & Sunil Kunisetty, Publisher JavaDevelopersJournal). Tips:

• Clustering can be achieved separately for each tier: web cache, web server, application server, database server.
• Efficient clustering needs load balancing (distributing requests to balance the load across the cluster).
• Load Balancing Strategies include: Random; Round-robin; Weighted; Equal request (equal weighting); Equal client (requests dispatched based on the client); Equal workload (theoretically ideal but often difficult or too expensive to achieve).
• Stateless sessions are considerably more efficient to replicate over a cluster.
• Clustering without replication is more efficient but less fault tolerant.
• Speeding serialization usually helps performance. Using readObject/writeObject [or Externalization] can significantly improve serialization performance.

http://www.devx.com/java/free/articles/kabutz08/Kabutz08-1.asp
JDBC drivers (Page last updated September 2002, Added 2002-10-30, Author Heinz Kabutz, Publisher DevX). Tips:

• If your application uses the database continuously, you need to have as little overhead in your driver as possible.
• If database access is not a bottleneck, the driver performance is not so important. It may be more important that it does not leak memory.
• When inserting large amounts of data using setBytes(), type 4 drivers can be significantly slower than type 1 drivers for some databases.

http://www.sys-con.com/java/article.cfm?id=1663
Scaling J2EE (Page last updated October 2002, Added 2002-10-30, Author Mikhail Skorik, Publisher JavaDevelopersJournal). Tips:

• Scale horizontally by using multiple external (load balanced) servlet containers to dedicate application server resources to EJB processing. This architecture enables separate scaling of the presentation layer and the business logic layer.
• Use cached Value Objects in servlet containers to reduce the number of requests made to the application server.
• Use JMS to notify Value Object caches of any changes which invalidate a cached Value Object to get near real-time update of the cached Value Objects.

http://developer.java.sun.com/developer/JDCTechTips/2002/tt0924.html
File Locking (Page last updated September 2002, Added 2002-10-30, Author John Zukowski, Publisher Sun). Tips:

• Exclusive locking will serialize all access to a file, instead of permitting simultaneous reads or access to different sections of a file. (Note that if shared locking is not available on a platform then exclusive locking is automatically used.)

http://www.onjava.com/pub/a/onjava/2002/10/02/javanio.html
NIO (Page last updated October 2002, Added 2002-10-30, Author Ron Hitchens, Publisher OnJava). Tips:

• Direct buffers can be used from both sides of the JNI, allowing efficiencies such as direct memory manipulation without having to pass data through the JNI.
• Memory mapped files use less system memory since the file data is held in page space only, rather than page space and JVM heap space.
• Multiple memory mappings of any single file only requires one real memory mapping into the page file.
• Scatter/gather operations allows multiple (old) I/O operations to be performed in fewer NIO operations.
• FileChannel.transferTo() and FileChannel.transferFrom() allows data to be transferred between two file channels in the most efficient way.
• Non-blocking sockets allows threads to efficiently check for I/O without blocking.
• Multiplexing I/O avoids polling overheads and enables I/O on multiple channels using the minimum of resources.

http://www2.theserverside.com/resources/article.jsp?l=MonsonHaefel-Column4
The Timer service (Page last updated October 2002, Added 2002-10-30, Author Richard Monson-Haefel, Publisher TheServerSide). Tips:

• [Article describes the EJB Timer Service which allows tasks to be scheduled, and suggests improvements based on cron].
• [Note an alternative implementation of the the timer service for earlier EJBs discussed in http://www.sys-con.com/websphere/article.cfm?id=150].

http://otn.oracle.com/oramag/oracle/02-sep/o52jdbc.html
JDBC tips (Page last updated September 2002, Added 2002-10-30, Author William Crawford, Publisher Oracle). Tips:

• Pool your connections.
• Use PreparedStatements and close them when finished.
• Use transactions optimally: no auto-commit mode; the lowest transaction isolation level consistent with the application; minimize transactions and don't let the user control when they finish.
• Use database-side processing where this improves performance, such as reducing the number of SQL statements needing to be executed by using more complex SQL or stored procedures.
• Use the fastest driver.
• Optimize the network configurations of your machines and the network connections between your database server and Web/Application server.

http://portals.devx.com/Brew/Article/8124
Smooth animation/sprite engine requirements (Page last updated September 2002, Added 2002-10-30, Author Chris Preimesberger, Publisher DevX). Tips:

• Use transparent pixels to smooth sprite images.

http://www-106.ibm.com/developerworks/java/library/j-ebb0917b.html
Swing multi-threading (Page last updated September 2002, Added 2002-10-30, Author Guruprasad H.N., Publisher IBM). Tips:

• Use invokeLater() and invokeAndWait() with Swing to avoid threading problems.

http://java.ittoolbox.com/documents/document.asp?i=2028
Row level locking (Page last updated September 2002, Added 2002-10-30, Author Nicholas Whitehead, Publisher ITtoolbox). Tips:

• Use "SELECT <select statement> FOR UPDATE [nowait]", eg. "select empno from EMP for update nowait" to lock a row. The nowait makes your statement fail immediately if another user is holding the lock. Otherwise, it will simply wait for the current user to complete or cancel the transaction.

http://www.informit.com/content/index.asp?product_id={98614A3F-B3EA-4167-BA4E-3C774E48CFE1}
Chapter 3, "Popular Unix Performance-Monitoring Tools for Linux" from "Linux Performance Tuning and Capacity Planning" (Page last updated October 2002, Added 2002-10-30, Author Jason Fink, Publisher InformIT). Tips:

• [Nice introductory coverage of Unix OS level free performance monitoring tools.]