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!

The following pages have their detailed tips extracted below

• Designing remote interfaces
• Performance tuning report in German
• Article on using smart proxies.
• Overview of common application servers
• Design patterns catalog
• EJB design
• Command objects for RMI.
• Caching RMI stubs.
• J2EE design patterns to improve performance
• EJB performance tips
• Clustering with JBoss
• Chapter 10, "Serialization" from "Java RMI"
• EJB performance tips
• RMI performance tuning
• Chapter 4 of "Enterprise Java Performance", "Local/Remote Issues".
• How to use java
• JMS vs RMI
• Weblogic's RMI framework
• Chapter 4, "I/O Performance" of "Java Platform Performance: Strategies and Tactics
• RMI arguments
• Data compression
• Monitoring Networked Applications

The following detailed tips have been extracted from the raw tips page

http://www.javaworld.com/javaworld/jw-03-2001/jw-0323-performance.html
Designing remote interfaces (Page last updated March 2001, Added 2001-04-20, Author Brian Goetz, Publisher JavaWorld). Tips:

• Remote object creation has overheads: several objects needed to support the remote object are also created and manipulated.
• Remote method invocations involve a network round-trip and marshalling and unmarshaling of parameters. This adds together to impose a significant latency on remote method invocations.
• Different object parameters can have very different marshalling and unmarshaling costs.
• A poorly designed remote interface can kill a program's performance.
• Excessive remote invocation network round-trips are a huge performance problem.
• Calling a remote method that returns multiple values contained in a temporary object (such as a Point), rather than making multiple consecutive method calls to retrieve them individually, is likely to be more efficient. (Note that this is exactly the opposite of the advice offered for good performance of local objects.)
• Avoid unnecessary round-trips: retrieve several related items simultaneously in one remote invocation, if possible.
• Avoid returning remote objects when the caller may not need to hold a reference to the remote object.
• Avoid passing complex objects to remote methods when the remote object doesn't necessarily need to have a copy of the object.
• If a common high-level operation requires many consecutive remote method calls, you need to revisit the class's interface.
• A naively designed remote interface can lead to an application that has serious scalability and performance problems.
• [Article gives examples showing the effect of applying the listed advice].

http://www.bastie.de/resource/res/mjp.pdf and http://www.bastie.de/java/mjperformance/contents.html
Performance tuning report in German. Thanks to Peter Kofler for extracting the tips. (Page last updated November 2001, Added 2001-07-20, Author Sebastian Ritter, Publisher Ritter). Tips:

• avoid remote method calls
• use callbacks to avoid blocking remote method calls
• use batching for remote method calls
• use externalization instead of serialisation

http://www.javaworld.com/javaworld/jw-11-2000/jw-1110-smartproxy.html
Article on using smart proxies. (Page last updated November 2000, Added 2001-01-19, Author M. Jeff Wilson, Publisher JavaWorld). Tips:

• Use smart proxies to monitor the performance of RMI calls.

http://win-www.uia.ac.be/~s985218/professional/thesis/archief/documenten/Marktoverzicht.doc
Overview of common application servers. (Announced at http://www.theserverside.com/home/thread.jsp?thread_id=9581). I've extracted the performance related features (Page last updated October 2001, Added 2001-10-22, Author Pieter Van Gorp, Publisher Van Gorp). Tips:

• Optimized subsystems (RMI, JMS, JDBC drivers, JSP tags & cacheable page fragments).

http://java.sun.com/blueprints/patterns/j2ee_patterns/catalog.html
Design patterns catalog (Page last updated 2001, Added 2002-01-25, Author ?, Publisher Sun). Tips:

• Use the Value Object pattern to efficiently transfer remote, fine-grained data by sending a coarse-grained view of the data.

http://www.sys-con.com/java/article.cfm?id=1268
EJB design (Page last updated January 2002, Added 2002-01-25, Author Boris Lublinsky, Publisher Java Developers Journal). Tips:

• Some application server implementations (e.g., WebSphere) automatically convert remote communications to local communications to make them faster.
• Local interfaces in EJB 2.0 is one attempt to improve overall performance: local interfaces provide for beans in the same container to interact locally without involving RMI.

http://www.onjava.com/pub/a/onjava/2001/10/17/rmi.html
Command objects for RMI. (Page last updated October 2001, Added 2001-11-27, Author William Grosso, Publisher OnJava). Tips:

• Use Command objects to automatically queue or retry RMI calls.

http://www.onjava.com/pub/a/onjava/2001/10/31/rmi.html
Caching RMI stubs. (Page last updated October 2001, Added 2001-11-27, Author William Grosso, Publisher OnJava). Tips:

• Remote method calls are much slower than local calls, at least 1000 times slower.
• Reduce the number of remote calls made by an application to improve performance.
• Cache remote objects locally where possible, rather than repeatedly fetching them.
• Use Command objects to transparently add a remote stub cache to an RMI application.
• Caching stubs keeps them from being garbage collected, and may prevent an RMI server from closing. Use a policy to expire stubs and delete them from the cache.

http://www.javaworld.com/javaworld/javaone01/j1-01-patterns.html
J2EE design patterns to improve performance (Page last updated June 2001, Added 2001-06-18, Author Daniel H. Steinberg, Publisher JavaWorld). Tips:

• Combine multiple remote calls for state information into one call using a value object to wrap the data (the Value Object pattern, superceded by local interfaces in EJB 2.0).
• Where long lists of data are returned by queries, use the Page-by-Page Iterator pattern: a server-side object that holds data on the server and supplies batches of results to the client.

http://www.precisejava.com/javaperf/j2ee/EJB.htm
EJB performance tips (Page last updated November 2001, Added 2001-12-26, Authors Ravi Kalidindi and Rohini Datla, Publisher PreciseJava). Tips:

• Change multiple remote method calls into one remote method call with all the data combined into a parameter object.
• Control serialization by modifying unnecessary data variables with 'transient' key word to avoid unnecessary data transfer over network.

http://www.onjava.com/pub/a/onjava/2002/07/10/jboss.html
Clustering with JBoss (Page last updated July 2002, Added 2002-07-24, Authors Bill Burke, Sacha Labourey, Publisher OnJava). Tips:

• Smart proxies can be used to implement load-balancing and fail-over for EJB remote clients. These proxies manage a list of available RMI connections one of which it will use to service an invocation.

http://www.onjava.com/pub/a/onjava/excerpt/JavaRMI_10/index.html
Chapter 10, "Serialization" from "Java RMI" (Page last updated November 2001, Added 2001-12-26, Author William Grosso, Publisher OnJava). Tips:

• Use transient to avoid sending data that doesn't need to be serialized.
• Serialization is a generic marshalling mechanism, and generic mechanisms tend to be slow.
• Serialization uses reflection extensively, and this also makes it slow.
• Serialization tends to generate many bytes even for small amounts of data.
• The Externalizable interface is provided to solve Serialization's performance problems.
• Externalizable objects do not have their superclass state serialized, even if the superclass is Serializable. This can be used to reduce the data written out during serialization.
• Use Serializable by default, then make classes Externalizable on a case-by-case basis to improve performance.

http://www.fawcette.com/javapro/2001_12/magazine/features/kkothapalli/
EJB performance tips (Page last updated December 2001, Added 2001-12-26, Author Krishna Kothapalli and Raghava Kothapalli, Publisher JavaPro). Tips:

• Combine remote method calls into one call, and combine the data required for the calls into one transfer.

http://www.javaworld.com/jw-09-2001/jw-0907-rmi.html
RMI performance tuning (Page last updated September 2001, Added 2001-10-22, Author Ashok Mathew and Mark Roulo, Publisher JavaWorld). Tips:

• Use netperf to measure network bandwidth.
• Consider altering the TcpWindowSize parameter.
• Configure RMI garbage collection by setting the properties sun.rmi.dgc.client.gcInterval and sun.rmi.dgc.server.gcInterval.
• Send groups of objects together rather than one object at a time.
• Implementing Externalize can speed up transfers.
• Pack data to reduce the number and amount of reads and writes, and the amount of data transferred.
• Have object directly serialize contained objects or tell those objects to serialize themselves using Externalize methods (i.e. chain Externalize methods for all contained objects).
• Use special codes to handle special cases such as singleton or reusable objects.
• Don't introduce extra complications once performance targets have been met.

http://developer.java.sun.com/developer/Books/programming/performance/eperformance/eJavaCh04.pdf
Chapter 4 of "Enterprise Java Performance", "Local/Remote Issues". (Page last updated 2000, Added 2000-10-23, Authors Steven Halter & Steven Munroe, Publisher Sun). Tips:

• RMI over IIOP has a higher overhead than plain RMI.
• Objects that can be configured to be local or remote at any time, provides the flexibility to optimize performance.
• Large grained remote calls [i.e. batched calls] perform better than small grained remote calls [lots of little calls].
• Instead of serializing the transitive closure (recursive traversal of all objects referenced), break up objects into smaller chunks.
• Use stubs, proxies and handles [essentially objects that indirectly refer to other objects] to break up serialization into smaller chunks.
• Unless the application is put together with care, the remote method call costs may dominate.
• Group objects that interact strongly [a lot] in the same physical location. The closer they are, the more efficient their interaction.
• Cache in the client any read-only objects, for the whole session. Replicate any data needed so that queries run locally in the client.
• Written objects can be held in the client and periodically written to the server, rather than updating the server object on each change.
• Good partitioning of objects in distributed applications limits interactions between objects in different partitions and takes advantage of local method access for objects within each partition.
• Application partitioning is best addressed early in the design.

http://developer.java.sun.com/developer/JDCTechTips/2001/tt0327.html
How to use java.rmi.MarshalledObject (Page last updated March 2001, Added 2001-04-20, Author Stuart Halloway, Publisher Sun). Tips:

• MarshalledObject lets you postpone deserializing objects. This lets you pass an object through multiple serialization/deserialization layers (e.g. passing an object through many JVMs), without incurring the serialization/deserialization overheads until absolutely necessary.

http://www.devx.com/premier/mgznarch/Javapro/2002/03mar02/kj0302/kj0302-1.asp
JMS vs RMI (Page last updated February 2002, Added 2002-02-22, Author Kevin Jones, Publisher DevX). Tips:

• RMI calls marshall and demarshall parameters, adding major overhead.
• Every network communication has several overheads: the distance between the sender and the receiver adds a minimum latency (limited by the speed the signal can travel along the wire, about two-thirds of the speed of light: London to New York would take about 3 milliseconds); each network router and switch adds time to respond to data, on the order of 0.1 milliseconds per device per packet.
• Part of most network communications consists of small control packets, adding significant overhead.
• One RMI call does not generally cause a noticeable delay, but even tens of RMI calls can be noticeable to the users.
• Beans written with many getXXX() and setXXX() methods can incur an RMI round trip for every data attribute.
• Messaging is naturally asynchronous, and allows an application to decouple network communications from ongoing processing, potentially avoiding threads from being blocked on communications.

http://www.weblogic.com/docs51/techoverview/rmi.html
Weblogic's RMI framework (Page last updated January 1999, Added 2001-03-21, Author , Publisher BEA). Tips:

• Use a single, multiplexed, asynchronous, bidirectional connection for RMI client-to-network traffic instead of the standard reference implementation using multiple sockets.
• Try to improve the serialization mechanism for faster RMI [Externalization is better].
• Use local calls for objects located in the same JVM.
• Minimize distributed garbage collection.
• Use smart stubs which provide data caching and localized execution in addition to the normal remote execution and data fetching capabilities.

http://java.sun.com/docs/books/performance/1st_edition/html/JPIOPerformance.fm.html
Chapter 4, "I/O Performance" of "Java Platform Performance: Strategies and Tactics." (Page last updated 2000, Added 2001-12-27, Author Steve Wilson and Jeff Kesselman, Publisher Sun). Tips:

• Default Serialization is slow.
• Use the transient keyword to define fields to avoid having those fields serialized. Examine serialized objects to determine which fields do not need to be serialized for the application to work.

http://www.javareport.com/html/from_pages/article.asp?id=5769&mon=12&yr=2001
RMI arguments (Page last updated December 2001, Added 2002-02-22, Author Scott Oaks, Publisher Java Report). Tips:

• Some application servers can automatically pass parameters by reference if the communicating EJBs are in the same JVM. To ensure that this does not break the application, write EJB methods so that they don't modify the parameters passed to them.

http://www.javaworld.com/javaworld/javaqa/2001-12/01-qa-1207-ziprmi.html
Data compression (Page last updated December 2001, Added 2001-12-26, Author Tony Sintes, Publisher JavaWorld). Tips:

• [Article covers how to add zip compression to RMI communications].

http://www.messageq.com/systems_management/currie_1.html
Monitoring Networked Applications (Page last updated March 2002, Added 2002-04-26, Author Russ Currie, Publisher Message MQ). Tips:

• Use network probes to break down how the network is being used by the various networked applications on it.