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

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.]

Back to newsletter 023 contents