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!

Back to newsletter 029 contents

http://www.informit.com/isapi/product_id~{AFB2EC69-5AF9-46A4-BC64-5AB282552FF2}/content/index.asp
J2EE perf tuning 1 (Page last updated 2003 March, Added 2003-04-28, Author Steven Haines, Publisher informIT). Tips:

• The goal of performance tuning is to service more users faster and not break down in the process. This requires maximizing: Concurrent users; Throughput (transactions performed per second); Reliability.
• Load test the application running in your application server and estimate the number of concurrent users it can support before requests start failing and/or the response time does not meet your requirements.
• Ensure that you have representative transactions that reflect the real use of your application; If it is not representative, there are no guarantees that your application will stand up to real users.
• Tune to maximize the throughput of the server.
• Tuning includes minimizing the number of failed requests. All servers will produce some failures mostly due to network latency or timeouts.
• You need to tune both the application code and the application server configuration. You also need to tune any resources these two depend on, so that they are not waiting on external resources (such as the database).

http://www.informit.com/content/articlex.asp?product_id={F35A459F-C8EF-49D5-9F14-01A25768DBE3}
J2EE perf tuning 2 (Page last updated 2003 March, Added 2003-04-28, Author Steven Haines, Publisher informIT). Tips:

• Analyse (expected) user activity and generate load tests based on that activity.
• Measure performance metrics from the application, application server, underlying platform, and any external resources.
• A load tester can: perform user-defined transactions on a system with a given frequency; control the number of simultaneous users in the load; simulate user think-time between requests; and increase the number of users in a test according to a defined rate.
• Statistics to gather include: Application Server memory usage, database connection usage, thread usage; Application class or method response times, call paths, exceptional methods; Application total transaction rates and requests rates; Platform CPU, processes; Database performance; legacy system performance.
• JMX provides a standard mechanism for obtaining configuration and runtime information for Java products. Application code needs to be instrumented to obtain relevant application performance statistics.
• Tuning is an iterative process: Start with a configuration that "looks good," load test the system, observe performance, change parameters, and start over.
• Pay particular attention to the concurrent user load and the transaction throughput of the system.
• The greater the throughput, the better the performance.

http://www.informit.com/content/index.asp?product_id={5E454C58-FD93-4080-937C-EA4372B9D337}
J2EE Performance Tuning, Part 3: Application Server Architecture (Page last updated 2003 April, Added 2003-04-28, Author Steven Haines, Publisher informIT). Tips:

• The size of your connection pools can greatly impact the performance of your application. When tuning, JDBC connection pool size is one of the factors with the highest impact on your application's overall performance.
• Tune to minimize activation and passivation of cached beans, and to maxmimize cache hits.
• The size of bean pools must be large enough to service the requests from business processes without having to wait for a bean before it can complete its work. If the pool size is too small, there are too many processes waiting for beans; if the pool size is too large, you are using more system resources than you actually need.
• Two of the most influential tuning parameters of Stateless Session Bean and Message Driven Bean pools are the size of the pools that support them and the number of beans preloaded into the pools.
• Tune the session timeout to avoid retaining unused resources too long in the server, while avoiding inconveniencing slow users.
• If JMS thresholds are too low, messages will be lost; if JMS thresholds are too high and the server is used to an excessive upper limit, it can degrade the performance of your entire system.
• JMS tuning parameters include: Message Delivery Mode (persistent or non-persistent); Time-to-live (defines a expiration time on a message); Transaction States; Acknowledgments.
• EJB choice of method transaction levels affects performance: Supported is the lowest cost; Required is safe, but a little more costly; and Requires New is probably the most expensive.
• The size of the application server thread pool limits the amount of work your application server can do; the tradeoff is that there is a point at which the context-switching (giving the CPU to each of the threads in turn) becomes so costly that performance degrades.
• The JVM heap size is important to performance. The rule-of-thumb is to give the application server all the memory that you can afford to give it on any particular machine.
• Your goal when tuning garbage collection is to size the generations to maximize minor collections and minimize major collections.

http://www.javaworld.com/javaworld/jw-03-2003/jw-0307-j2segc.html
1.4.1 garbage collectors (Page last updated 2003 March, Added 2003-04-28, Author Greg Holling, Publisher Javaworld). Tips:

• [Article describes the six garbage collectors available from 1.4.1].
• Incremental garbage collection (-Xincgc) provides shorter, but more frequent pauses for garbage collection. Overall garbage collection may take longer.
• The parallel (multithreaded) algorithms (-XX:+UseParNewGC, -XX:+UseParallelGC) are optimized for machines with multiple CPUs.
• The parallel scavenging collector (-XX:+UseParallelGC) is optimized for very large (gigabyte) heaps.
• The concurrent garbage collection (-XX:+UseConMarkSweepGC) allows the stop-the-world phase to be as short as possible, which means that application pauses for garbage collection should be minimized.
• If you have a single-processor client machine and are having problems with pause times in your application, try the incremental garbage collector
• If you have a single-processor server machine with lots of memory and experience trouble with application pause times, try the concurrent garbage collector.
• If you have a multiprocessor machine, especially with four or more processors, try one of the parallel garbage collection algorithms. These should significantly decrease pause times. If you have lots of memory (gigabytes), use the scavenging collector; otherwise, use the copying collector.
• Don't even consider changing GC parameters until you've profiled and optimized your application.

http://www.javaspecialists.co.za/archive/Issue064.html
Disassembling Java Classes (Page last updated 2003 January, Added 2003-04-28, Author Heinz Kabutz, Publisher Kabutz). Tips:

• Disassembling i++ and ++i show that these have identical code, so neither one can be faster than the other.

http://www-106.ibm.com/developerworks/java/library/j-jtp02183.html
Immutable objects (Page last updated 2003 February, Added 2003-04-28, Author Brian Goetz, Publisher IBM). Tips:

• You can share and cache references to immutable objects without having to copy or clone them
• Immutable objects are inherently thread-safe, so you don't have to synchronize access to them across threads.
• The Flyweight pattern employs a factory method to provide immutable objects, giving out the same instance for objects of the same value.
• util.concurrent.CopyOnWriteArrayList creates a new array when the list is modified. This allows iterators to be immutable and therefore traversed without synchronization or risk of concurrent modification, eliminating the need to either clone the list before traversal or synchronize on the list during traversal. If traversals are much more frequent than insertions or removals such as with event listener classes, CopyOnWriteArrayList offers better performance than ArrayList.

http://www.theserverside.com/resources/articles/RodJohnsonInterview/article.html
Rod Johnson interview (Page last updated 2003 February, Added 2003-04-28, Author TheServerSide, Publisher TheServerSide). Tips:

• Several benchmarks have indicated that using entity beans usually leads to poor performance, yet many developers simply ignore this. Use entity beans when required, not just in every case.
• Performance is an important business requirement, and systems that don't perform don't meet business expectations.
• Sometimes a stored procedure can provide much more efficient persistence (and more concise code) than Java code.

http://www.theserverside.com/resources/articles/RodJohnsonInterview/JohnsonChapter4.pdf
Chapter 4 of Expert1on1, Design Techniques and Coding Standards (Page last updated 2003 January, Added 2003-04-28, Author Rod Johnson, Publisher Wrox). Tips:

• Program to an interface, not an implementation. There is a slight performance penalty for calling an object through an interface, but this is seldom an issue in practice, whereas the ability to change the implementing class of any application object without affecting calling code allows performance improvements to be made easily an selectively
• The disadvantage of parameter consolidation is the potential creation of many objects, which increases memory usage and the need for garbage collection. Objects consume heap space; primitives don't.
• Consolidating method parameters in a single object can occasionally cause performance degradation in J2EE applications if the method call is potentially remote (a call on the remote interface of an EJB), as marshaling and unmarshaling several primitive parameters will always be faster than marshaling and unmarshaling an object. However, this isn't a concern unless the method is invoked particularly often (which might indicatepoor application partitioning ? we don't want to make frequent remote calls if we can avoid it).
• Code that uses reflection is usually slower than code that uses normal Java object creation and method calls, however, this seldom matters in practice, and the overhead of reflection is usually far outweighed by the time taken by the operations the invoked methods actually do.
• Unnecessary optimization that prevents us from choosing superior design choices is harmful.
• The overhead added by the use of reflection to populate a JavaBean when handling a web request won't be detectable.
• In some cases such as when replacing a lengthy chain of if/else statements, reflection will actually improve performance.
• StringBuffer is more efficient than concatenating strings with the + operator.
• Console output may also seriously degrade performance when running in some servers.
• Correct use of a logging framework should have negligible effect on performance
• It's important to ensure that generating log messages doesn't slow down the application. If a log message might be slow to generate, it's important to check whether or not it will be displayed before generating it.
• Log settings that show the class, method and line number should be switched off in production, as it's very expensive to generate this information
• Writing log messages to the console or to a database will probably be much slower than writing to a file.
• All logging packages should allow automatic rollover to a new log file when the existing log file reaches a certain size. Allowing too large a maximum file size may significantly slow logging, as each write to the file may involve substantial overhead.

http://wireless.java.sun.com/midp/ttips/optimize/
J2ME Optimization Tips and Tools (Page last updated 2002 November, Added 2003-04-28, Author Eric D. Larson, Publisher Sun). Tips:

• Obfuscation is a great way to reduce the size of your finished product.
• Code optimization should be postponed until the very end of the development cycle.
• Use System.currentTimeMillis() to accurately determine the amount of time it takes to execute a given block of code.
• The J2ME Wireless Toolkit version 1.0.4 includes a profiler tool. The profiler is the main tool used to pinpoint performance problems.
• java.lang.Runtime class's totalMemory() and freeMemory() methods are useful for monitoring your heap size.
• The 1.0.4 version of the J2ME Wireless Toolkit allows you to set the heap size, along with storage size (for RMS), and also the VM speed emulation and network throughput emulation to help you gauge performance of your application in your development environment before you deploy.
• Version 1.0.4 of the toolkit also includes a real-time memory monitor.
• To see when the system is performing garbage collection, enable the toolkit's Trace Garbage Collection option.
• To keep heap space free, be sure to set objects to null as soon as you're done with them.
• Set an Image to null after a paint to free up a good chunk of memory.
• (J2ME only tip) Explicitly call the System.gc() method to manage the GC schedule. Instead of just letting the system garbage-collect at its own discretion, try calling System.gc() when you know the user will be reading a screen and thus won't be interacting with the application immediately.

http://www.sys-con.com/java/article.cfm?id=1855
Java 3D (Page last updated 2002 July, Added 2003-04-28, Author Dan Pilone, Publisher JavaDevelopersJournal). Tips:

• Be aware of your memory allocation particularly in behaviors. To many garbage collections will destroy the 3D flow.
• Carefully lay out your scenegraph and be aware that rendering is happening in a separate thread. Java 3D could render frames between updates, causing strange inter-frame effects.

Jack Shirazi

Back to newsletter 029 contents