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

http://www-128.ibm.com/developerworks/library/j-memusage/
Monitoring your Java applications' Windows memory usage (Page last updated November 2004, Added 2005-02-28, Author Emma Shepherd, Martin Trotter, Caroline Maynard, Matthew Peters, Publisher IBM). Tips:

• Java process memory consists of: objects in the heap; bytecode for the program; JIT code; native code; some metadata (exception tables, line number tables and so on); native libraries (which can be shared between processes).
• Determining a Java application's true footprint can be a difficult task.
• Windows uses a demand-paged virtual memory system: virtual pages that can be mapped into real memory; committed pages that are loaded into main memory only when the process first references them, hence the name on-demand paging [explained in more detail in the article].
• Reserved space is the area of the address space has been reserved for future use by the process but can't be accessed until it has been committed. A lot of the Java heap starts off as reserved (the Xmx parameter specifies reserved memory).
• The two most common Windows performance monitoring tools are Task Manager and PerfMon, both bundled with Windows.
• Windows Task Manager is a fairly simple Windows process monitor. You can access it with the familiar Ctrl-Alt-Delete key combination, or by right-clicking on the Taskbar. It allows you to monitor memory size, CPU usage, and amounts of I/O operations.
• Windows PerfMon allows highly detailed monitoring of Windows processes. Useful PerfMon memory counters are: Working Set; Private Bytes; Virtual Bytes; Page Faults/sec; Committed Bytes.
• PrcView (available for download) lets you inspect the contents of a process's address space.
• TopToBottom (available for download) provides startup details of processes as well as detailed DLL memory information.
• VADump (available for download) is a command line tool that will dump an overview of the virtual address space and resident set for a particular process.
• Sysinternals ListDLLs allows you to monitor memory from scripts.
• Sysinternals Handle allows you to monitor I.O handles of a process.

http://www.onjava.com/pub/a/onjava/2004/11/24/replication1.html
Session Replication in Tomcat 5 Clusters (Page last updated November 2004, Added 2005-02-28, Author Srini Penchikala, Publisher OnJava). Tips:

• Broadcast regular heartbeat messages: by monitoring these heartbeat messages, server instances in a cluster can determine when a server instance has failed.
• NIO select based socket communication is more efficient than java.io polling - polling has a significant CPU overhead.
• Sticky sessions are sessions that stay on the single server that received the web request. If that server goes down the user has to log on again - but sticky sessions are more efficient as they have no distribution or coherence overheads.
• Replicated sessions are copied to all servers in the cluster - session data is copied everytime the session is modified. This has some overheads, but does provide session failover support.
• Sharing a multicast address may overload the IP multicast buffer and delay transmission of messages, so you should dedicate multicast addresses to the application to minimize overheads.
• Synchronized Token and Idempotent Receiver design patterns allow duplicate requests to be handled without increasing overheads.
• If state has to be rebuilt by retrieving data from a database, this completely defeats the purpose of using stateless session beans to improve performance and scalability, and can severely degrade performance.
• Serializing session data has overhead and this overhead increases as the size of serialized objects grows.
• The maximum number of concurrent clients and how frequently each client will be making a request factors in deciding how session replication will impact on the server performance.
• You can use a delta manager to transfer only changes in data rather than whole objects, to minimize serialization overheads.
• Use asynchronous replication to minimize response times, i.e. where the replication time is not crucial, but the request time is.
• Synchronous replication doesn't return until all nodes in the cluster have received the session data, so using synchronous mode could potentially become a bottleneck in the cluster's performance.
• If you need to replicate synchronously across nodes, use multiple sockets to send the data in parallel to minimize the total replication delay.
• Do not replicate static content.
• Do not replicate invalid sessions.

http://www-106.ibm.com/developerworks/websphere/techjournal/0410_woolf/0410_woolf.html
Eliminate caching in service locator implementations in J2EE 1.3 (Page last updated October 2004, Added 2005-02-28, Author Bobby Woolf, Publisher IBM). Tips:

• The Service Locator pattern encapsulates code for accessing components through directory services, such as JNDI client code, so that a client can simply pass in the name of a resource and get back that resource.
• Service locator implementations usually include a resource cache to avoid repeated lookups of the same resource.
• In J2EE 1.3 caching can introduce subtle and difficult-to-diagnose errors into applications: J2EE 1.3 applications should not include the resource cache in their service locator implementations.
• In J2EE 1.3, each component (that is, each EJB bean class and each Web application) defines its own set of resource names, where each component's set of names is independently bound to a set of container resources. This means that two components can refer to the same resource name, yet actually be bound in production to access two different container resources - resource names are component-scoped, not global. A Service Locator resource cache that doesn't handle this correctly can return the wrong resource.
• When resource lookups are expensive, caching improves performance by avoiding the repeated lookup of the same resource.
• As of J2EE 1.3, JNDI lookups perform much better and caching lookups does not help as much.
• Do not just assume that a caching service locator significantly improves application performance; use performance testing to confirm that it does.
• Fast code that doesn't work right is [usually] no good.
• Caching should not change behavior, results must be the same with or without caching.
• The best way to cache is for an object to store any JNDI reference it uses in an instance variable.
• Use a unique service locator instance per component type strategy to minimize overheads while still correctly supporting J2EE 1.3
• Ideally, do not cache in the application, cache in the container. This would make the performance benefits of caching transparently available to all applications (WebSphere does this).

http://www-106.ibm.com/developerworks/websphere/techjournal/0410_col_willenborg/0410_col_willenborg.html
Selecting performance tools (Page last updated October 2004, Added 2005-02-28, Author Ruth Willenborg, Publisher IBM). Tips:

• Choose a good code profiler and use it during application development. A code profiler helps identify and optimize code hot spots, and really helps in understanding object usage and potential memory leaks.
• Common scalability problems, including synchronization issues and database contention, do not surface until load tests.
• Invest in a good load test environment, as close to the production environment as possible.
• Most profilers introduce extremely high performance overhead, and so are not designed to effectively showcase performance data in a highly concurrent environment. Therefore, analyzing performance at this stage requires different tools.
• Measure usage of resources such as pools and caches, J2EE application metrics such as response time and number of requests, and basic system metrics (CPU, memory, I/O).
• Apply additional analysis to particularly slow and frequently used servlets or EJB components.
• A set of thread dumps of the JVM often pinpoints synchronized methods and other common problems.
• Runtime profilers provide detailed views of where time is spent in your application and often include capabilities to view performance down to specific SQL calls, and also pinpoint the cause of memory leaks.
• Having a good production monitoring strategy is a necessity.
• A Web site monitoring strategy requires the ability to view performance from the end-user perspective, understanding the health of all the systems within the Web site (including Application Server as well as database servers, directory servers, and other componentry). At a minimum, monitor these three categories, including report and alerting capabilities.

Jack Shirazi Back to newsletter 051 contents