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

http://www.onjava.com/pub/a/onjava/2004/03/17/lazyAspects.html
Lazy Loading with Aspects (Page last updated March 2004, Added 2004-05-31, Author Russ Miles, Publisher OnJava). Tips:

• Lazy loading delays class loading & instantiation until necessary, thus making startup time faster.
• Lazy loading should not be interleaved with business logic as that closely couples the the lazy loading to the class functionality, making it difficult to add or eliminate lazy loading as a an optimization.
• [Article shows how lazy loading can be modularized with AspectJ].

http://www-106.ibm.com/developerworks/library/j-perf03174.html
MegaJogos scales up with NIO (Page last updated March 2004, Added 2004-05-31, Author Jack Shirazi Kirk Pepperdine, Publisher IBM). Tips:

• UNIX operating systems set thread limitations, which you can reset per-user with the ulimit utility, reset in the kernel by recompiling the Linux kernel and glibc.
• NIO multiplexing allows a server to put service all blocked socket threads in one thread. This results in a more scalable server.
• A fully utilized CPU may not necessarily indicate a CPU bound application: in the case here of a conitnously polling application the CPU was always fully utilized but increased activity still scaled linearly.
• Sockets are normally ready for writing without blocking if a write to the network buffer for that socket can execute.
• Registering a newly created socket with the Selector in WRITE mode will cause the Selector.select() call to always return immediately, since the socket can immediately write without blocking.

http://weblogs.java.net/pub/wlg/1101
J2EE Performance Tips (Page last updated March 2004, Added 2004-05-31, Author Carol McDonald, Publisher java.net). Tips:

• You need to plan for performance and scalability through out your application development process from architecture to implementation to testing.
• CPU problems: watch for inefficient code especially for algorithms and loops Avoid excessive parsing and type conversions
• Too much memory use can affect performance by causing longer and frequent garbage collection.
• Make sure that any unused objects are no longer referenced so that the garbage collector can reclaim them.
• Take advantage of J2EE Application server caching and object pools.
• Garbage collection tuning can have a significant affect on performance .
• Design coarse-grained services with Session or MDB Facades and always use local interfaces for other EJBs.
• Use connection pooling and statement caching. Make sure your queries are efficient.
• Use the Data Transfer Object to encapsulate and pass a business object's data attributes to the presentation tier. Reduces remote network traffic and helps to keep a clean separation between JSPs and EJBs.
• Use the Service Locator to cache results of JNDI lookups
• Use the Value List Handler for querying, filtering, large amounts of data
• Use the Data Access Object to provide a simplified interface for performing complex JDBC operations and to encapsulate data-access logic. Allows decoupling of data-access optimizations
• Use the Session Facade: to group calls to EJBs in a Coarse Grained Interface; to use local interfaces for collocated beans; to group related entity or DB updates into 1 container managed transaction
• Don't store a lot of data in the HTTP Session.
• Remove servlet sessions when they are no longer needed.
• Call Bean.remove() when stateful session beans are no longer needed.
• Limit the size of objects in session beans (limit activation/passivation serialization costs).
• Convert Stateful EJBs to Stateless by adding parameters containing state information to the Stateless bean methods
• Tuned CMP entity beans can usually offer better performance then BMP entity beans.
• Optimistic locking gives better performance when entity contention is not high.
• Use a READ_COMMITTED isolation level with optimistic locking if there is a low likelihood of concurrent transactions updating the same rows.
• Set a sufficient size for the JVM's heap, Data Base connection pools, and EJB pools and caches, but too high resource settings can degrade performance as well by using too much memory.
• Tune the caching and pooling of EJBs and JDBC.
• Increase the bean's pool size when observing excessive creation and deletion of bean instances. Decrease the bean's pool size when accumulating a large number of instances in the pool.
• Caching beans gives better performance by reducing activations and passivations
• Avoid the accumulation of unused stateful bean instances in the cache.
• For Entity beans increase the cache size for beans with concurrent or iterative access patterns.
• For Stateful session beans set the cache size to the maximum estimated number of concurrent users.
• In general Increase the cache until a good cache hit rate is reached.
• Comit option B performs the best if the Entity bean will be accessed again. If the Entity bean is rarely reused then commit option C is better.
• Profile your application server to determine what works best.
• Tune the connection pool size.
• Close JDBC connections in the finally block
• Index the columns in your WHERE clauses
• Use EXPLAIN SELECT to analyze SQL queries. Aim to fully index queries, avoid n-way joins and avoid bring back too many rows.
• Turn off Auto-Commit, Group updates into a transaction and/or batch updates
• Use PreparedStatements and JDBC statement caching
• Don't overuse XML because parsing and processing can cause a performance hit.

http://weblogs.java.net/pub/wlg/1092
Patch Leaky Connections (Page last updated March 2004, Added 2004-05-31, Author Bob Lee, Publisher java.net). Tips:

• Make sure you close your JDBC resources.
• [Article and subsequent discussion discusses several ways to ensure you close JDBC resources].

http://wiki.java.net/bin/view/Javapedia/AlwaysUseStringBufferMisconception
AlwaysUseStringBufferMisconception (Page last updated June 2003, Added 2004-05-31, Author dubwai, Publisher java.net). Tips:

• Using StringBuffers when concatenating in a loop is good practice but otherwise, using the overloaded + operator with Strings is usually perfectly acceptable.

http://java.sun.com/developer/JDCTechTips/2004/tt0122.html#2
Monitoring Class Loading and Garbage Collection (Page last updated January 2004, Added 2004-05-31, Author John Zukowski, Publisher Sun). Tips:

• Use -verbose:gc to report on each garbage collection event.

http://wiki.java.net/bin/view/Linux/PerformanceTipsForJavaOnLinux
Monitoring Performance on Linux (Page last updated January 2004, Added 2004-05-31, Author JamesCLiu, Publisher java.net). Tips:

• Use "-Xrunhprof:cpu=samples,file=hprof.txt", and send kill -3 to generate the profiles.
• Use top, vmstat, mpstat, iostat and netstat to monitor the OS level performance caused by the Java application.
• If system time is more than 15% of total CPU, there's a good chance that some kernel or library tuning can significantly improve performance. If, however, one notices that the user time is more than 85%, then the place to look is more likely at inefficiencies either within the JVM itself or the Java code.

http://javaboutique.internet.com/articles/jvm_monitor/
JVM Monitoring and Management Specification (Page last updated April 2004, Added 2004-05-31, Author Benoy Jose, Publisher javaboutique). Tips:

• JSR 174 specification (implemented in the 1.5 JVM) proposes guidelines and recommendations for an API that can help to monitor JVMs, at less than 1% overhead.
• The JVM contains three memory pools and two memory managers: One pool is for object allocation (managed by the garbage collector); the second is the method area (also GC managed); the third is for native compiled code managed by a malloc/free manager; the first pool belongs to the heap memory and the others belong to the non heap memory.
• Non-heap memory can store data other than those stored in the heap, including runtime field and method data

http://www.fawcette.com/javapro/2003_03/magazine/features/odoerderlein/
Use Threading Tricks to Improve Programs (Page last updated March 2004, Added 2004-05-31, Author Osvaldo Pinali Doederlein, Publisher JavaPro). Tips:

• Synchronization can spoil potential JIT compilation optimizations.
• Synchronize only in your public interface, if possible. Acquiring an already owned lock is an inexpensive operation, but it's more expensive than not having to do anything.
• If you put a lot of data in a single entity (from the concurrency control perspective), access to this data won't scale well.
• For large complex objects, partition your data so that concurrent searching is broken down into a series of separately lockable actions.
• Use ThreadLocal objects to minimize concurrent lookup collisions.
• A multi-tiered thread-local/global-memory/external-store approach can minimize locking contentions.
• Writing efficient, scalable, multithreaded code may require fundamental changes in your design, so efficient concurrency is not usually an optimization task that can be performed late in the development process.
• Structuring your shared data to reduce locking contention is important.
• Less contention means less time is wasted on the worst-case scenario of synchronization and, more important, increases parallelism with SMP machines or scenarios where different threads use different execution resources.

http://www-106.ibm.com/developerworks/websphere/techjournal/0405_brown/0405_brown.html
J2EE best practices (Page last updated May 2004, Added 2004-05-31, Author Kyle Brown Keys Botzum Ruth Willenborg, Publisher IBM). Tips:

• Always use (large-grained) Session Facades whenever you use EJB components, and use local interfaces for the entity beans behind the Session Facade.
• Use stateless session beans instead of stateful session beans. Use the HttpSession to store user-specific state. J2EE application servers cannot load-balance requests to stateful beans.
• Use container-managed transactions.
• Prefer JSPs as your first choice of presentation technology. Performance tests done at IBM comparing the relative speed of XSL and JSP show that in most cases a JSP will be several times faster at producing the same HTML output as an equivalent XSL transform, even when compiled XSL is used.
• Store the minimum state you need for the current business transaction in your HttpSessions. Under 4K is a good rule-of thumb, under 2K is probably better. For larger session data use an in-memory hash table to cache the data and just keep a key to the data in the session.
• In WebSphere, turn on dynamic caching and use the WebSphere servlet caching mechanism.

http://www.javaworld.com/javaworld/jw-04-2004/jw-0405-bottleneck.html
J2EE data layer bottlenecks (Page last updated April 2004, Added 2004-05-31, Author Christopher Keene, Publisher JavaWorld). Tips:

• The two application characteristics that most frequently contribute to data bottlenecks are the number of data objects and the peak transaction rate.
• Any application that has an object model with 20 or more data objects will experience performance issues related to the object-relational mapping. Highly efficient object/relational mapping is necessary to prevent mapping bottlenecks.
• Object-relational mapping bottlenecks can be reduced by: lazy loading (load only the data that is needed); using stored procedures to map the objects to the data.
• Standard J2EE architecture produces one or more SQL queries for each data object access, quickly saturating the database server. These bottlenecks can be addressed by increasing database capacity through replication or by reducing database requests using caching inside the J2EE server.
• J2EE applications that have more than 50 data classes and/or more than 50 transactions per second during peak times are much more likely to experience serious data bottlenecks.
• Intelligent caching makes: objects accessible across transactions; objects accessible by reference, primary key, attribute, relationship, and indexed queries; caches complete object models, including relationships; sends changed state in sync messages; replicates changes across caches; maintains coherent caches.

Jack Shirazi

Back to newsletter 042 contents