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 059 contents

http://java.sun.com/developer/technicalArticles/J2SE/Desktop/mustang/splashscreen/
New Splash-Screen Functionality in Mustang (Page last updated September 2005, Added 2005-10-31, Author Oleg Semenov Dana Nourie, Publisher Sun). Tips:

• From 1.6, use the -splash parameter or SplashScreen-Image: jar Manifest option to display a splash screen as soon as possible during startup. [Note, performance is all about perception. Having a screen come up as quickly as possible, preferably giving feedback to the user about the application loading or some such, makes the application seem faster. This is potentially an important boost to the perception of startup performance].
• The java.awt.SplashScreen class allows you to access the splashscreen once application startup has started (i.e. after the JVM has initialized).

http://www.javaspecialists.co.za/archive/Issue115.html
Young vs Old Generation GC (Page last updated October 2005, Added 2005-10-31, Author Heinz Kabutz, Publisher javaspecialists). Tips:

• Avoid middle-aged objects - that is objects which are neither very short-lived nor very long-lived

http://www.samag.com/documents/s=9894/sam0511a/0511a.htm
Web Site Performance (Page last updated November 2005, Added 2005-10-31, Author Jeffrey Fulmer, Publisher SysAdmin). Tips:

• Compared to the actual sample of users, negative feedback is provided far more often than positive feedback. This skews feedback results and means it is not useful as a direct measurement of performance.
• The first step toward global performance improvement is comprehensive monitoring.
• Website performance needs to be gauged from the cutomer perspective - geographically spread customers means that your response time tests need to take into account the different connectivity of your customers
• Users of your web pages do not see your headers - the page is not "seen" until it is displayed by the browser. That means you need to factor in browser rendering time of your pages, i.e. you should see how long pages take to render independently of the download time.
• The page should download and render in less than a second where testing locally.
• The further a packet must travel, the longer it takes to complete its round trip time (RTT). Lengthy round trips usually occur through a series of routers.
• With TCP/IP each packet must be verified. If delivery verification fails, then the packet is re-sent after a timeout - packet loss results in re-sends which results in high latency. TCP is designed to avoid packet loss. The sender must receive acknowledgement for every packet sent. If a sender does not receive verification before a set timeout (200 ms in most cases), then it resends the packet and every one after it. If 20 packets were sent and packet 13 was lost, then packets 13 through 20 must be retransmitted.
• According to market research, if a page requires more than eight seconds to load, customers will leave the site.
• The more the number of router hops between the client and server, the more the latency froma combination of router overhead and increased likelihood of retransmitted packets.
• Appliance devices by F5, NetScaler, Red Line Networks, and FineGround provide inline compression and TCP optimization. Some offer HTTP protocol optimization and caching.
• Good Web systems are already using gzip to compress everything that is compressibleand expires or headers to set explicit cache directives on heavily requested elements. Their content is quick to generate and light over the wire.
• Reduce the number of server requests with explicit caching directives on the server.
• Distance delays can be corrected by distributing content closer to users. Caching reverse proxies in regional centres can be employed to move content closer to customers.

http://www.devx.com/Java/Article/29526
Add Object Cache Monitoring Using JMX and Aspects (Page last updated October 2005, Added 2005-10-31, Author Srini Penchikala, Publisher devX). Tips:

• You can use Aspect Oriented Programming (AOP) techniques to dynamically introduce JMX code into existing Java classes to get cache statistics, this allowing the monitoring overhead to be turned on and off.
• [The article provides an overview of an Object Caching Monitor framework developed using JMX and AOP technologies].
• When monitoring cache, you should monitor: how objects in the cache get cleaned up; the overall size of objects stored in the cache; when the cache size grows beyond a maximum allowed threshold and raise any alerts to cleanup the cache.
• Application monitoring provides several benefits: developers can monitor the applications to identify tuning and optimization opportunities; operations and network can monitor to detect O/S or server problems before they occur, and to trigger warnings when server statistics such as CPU or memory usage approach the maximum allowed limits.
• System Monitoring statistics to monitor include: OS Stats, CPU, Memory, I/O
• Network statistics to monitor include: Bandwidth, connection speed
• Server statistics to monitor include: Processor(s) details
• Application Server statistics to monitor include: Cluster, JMS Distributed Destinations, JDBC Connection Pool, Server Performance, Thread Pool
• Java EE Application statistics to monitor include: Cache Monitoring
• Database Server statistics to monitor include: Number of maximum and average DB connections, connection time
• One important cache statistic is the hit-miss ratio, which is defined as the number of hits that successfully access data stored in the cache versus the number of misses.
• A cache "miss" occurs when the data isn't cached, and the application must access the data from the backend database?either because this is the first request for that data, or because the cached data has expired.
• The higher the hit-miss ratio, the better the objects are being managed in the cache; thus the hit-miss ratio is a good measure of the effectiveness of the object cache.
• Aspect Oriented Programming (AOP) techniques allow you to dynamically add new monitoring capabilities in the application with minimal or no changes to the existing code.

http://dev2dev.bea.com/pub/a/2005/06/memory_leaks.html
Memory Leaks (Page last updated June 2005, Added 2005-10-31, Author Staffan Larsen , Publisher BEA). Tips:

• A program that creates too many objects will be slower than one that does the same thing with fewer objects (provided all other things are equal).
• If the program keeps references to objects that will never be used, the objects will hang around and eat up memory because the grabage collector cannot know the application no longer needs the objects.
• To ensure objects are no longer referenced by the application, references to them have to go out of scope (e.g. local variables when a method exits), or explicitly set object fields to null or remove objects from collections.
• Global data repositories are common places for unintentional object retention to occur.
• Caches are common places for unintentional object retention to occur. Either soft references should be used to hold them, or there needs to be a good cache element expiration algorithm.
• Classloaders are common places for unintentional object retention to occur. As long as there are references to fields, methods, classes, or objects of a ClassLoader, the ClassLoader will stay in the JVM. Since the ClassLoader itself can hold on to a lot of classes as well as all their static fields, quite a bit of memory can be leaked.
• Often your test environment does not exercise the application in quite the same way the production system does, resulting in a leak only showing up in production. To detect these you need low-overhead tools that monitor and search for the memory leak.
• an OutOfMemoryError is often a sign of a memory leak, but it is possible that the application really is using that much memory; in that case you either have to increase the amount of heap available to the JVM or change your application in some way to use less memory.
• Continuously monitor the GC activity to spot if the memory usage increases over time - If it does, you probably have a memory leak.
• The most widely used technique to monitor GC activity is to start the JVM with the -Xverbose:gc option and watch the output.
• [Article sells the benefits of the JRockit Memory Leak Detector, a low overhead detachable detector suitable for production systems].
• To identify the cause of a memory leak, you need to identify the leaking objects, and know is which other objects are holding on to the leaking objects.
• To limit the amount of data that needs to be analyzed to determine memory leaks, it is best grouped by class, i.e. class and number of objects leaking, and class and number of objects referencing the class of objects leaking.
• The most common memory leaks are from collection objects - and some of these collection objects are likely to grow very large as the memory leak continues. This can help you identify the memory leak, by looking for very large objects.
• Finding the size of collection objects can be done quickly for collections that are implemented by wrapping an array, by looking at the size of the wrapped array.
• The three-step approach to finding leaks is: First, do a trend analysis to find out which class of objects is leaking; Second, see which other classes are holding on to objects of the leaking class; Third, drill down to the individual objects and see how they are interconnected.

http://jdj.sys-con.com/read/131798.htm
Profiling memory (Page last updated October 2005, Added 2005-10-31, Author Calvin Austin, Publisher JDJ). Tips:

• Many slow memory leaks only occur at deployment time.
• JDK 5.0 included byte code insertion, which can be used by profiling tools to dynamically add monitoring at runtime.
• Sun JVM tools such as jmap and visualgc can provide a view into the garbage collectors operation.
• There is an improved hprof profile agent in JDK 5.0 that can be used to dump out profiling information in a format that can be used by the hat analysis tool from java.net.
• To generate a hprof file use the QUIT signal, kill -3 on Unix after starting the JVM with the hprof agent -agentlib:hprof=heap=all,format=b.
• If you have already sized your maximum heap correctly e.g., -Xmx512m, then an out of memory error is caused by objects holding onto references to other objects that are no longer required. As these objects are still reachable, and hence live, they will not be marked by the garbage collector as objects that can be deleted.
• Caches are prime suspects for unintentionally holding on to references, or collections and array.
• Make sure you null references from collections or use weak references.
• Check custom classloaders for unintentional object retention - they hold on to many references.
• If you're using finalizers, remember they may never get called if the objects are unintentionally retained.

Jack Shirazi Back to newsletter 059 contents