All Java performance tuning tips relevent to the analysis and design phases. More specific subgroups of tips may be accessed from the tips index page.

The following pages have their detailed tips extracted below

• Performance planning for managers
• A high level overview of technical performance tuning, covering 5 levels of tuning competence.
• Chapter 4 of "Java Performance Tuning", "Object Creation".
• Multiprocess JVMs
• Measuring JDBC performance
• Catching OutOfMemoryErrors
• Whoopee!! A non-blocking I/O library for Java
• For years, Jonathan Hardwick's old but classic site was the only coherent Java performance tuning site on the web
• Balancing Network Load with Priority Queues
• "Cutting Edge Java Game Programming"
• Designing remote interfaces
• Glen McCluskey's paper with 30 tuning tips, now free.
• Detailed article on load testing systems
• JDBC Performance Tips (targeted at AS/400, but generically applicable)
• Patrick Killelea's Java performance tips.
• Tutorial on the full screen capabilities in the 1.4 release (5 pages plus example pages under the top page)
• HP Java tuning site, including optimizing Java and optimizing HPUX for Java
• J2EE Application server performance
• Designing Entity Beans for Improved Performance
• Performance tuning report in German
• Accelerating GUI apps (after 1.4)
• Article about avoiding creating objects where possible.
• The Eight Fallacies of Distributed Computing
• Article on designing for performance focusing on interfaces
• HotSpot FAQ
• A different HP tip page on optimizing Java performance, from the "HP-UX Programmer's Guide for Java"
• Bill Venners on "the right way to optimize"
• Application performance tuning
• Object management article
• Website usability metrics
• Paper detailing the "Best Practices for Developing High Performance Web and Enterprise Applications" using IBM's WebSphere
• Tuning IBM's WebSphere product
• When synchronization is required
• J2EE worst practices
• Weblogic tuning (generally applicable Java tips extracted)
• Weblogic JDBC tuning
• JDBC optimizing for DB2
• J2EE Performance tuning
• Using nonblocking I/O and memory-mapped buffers in SDK 1.4.
• Combining apps in one JVM
• Coding standards with a small but interesting section (section 7.3) on optimizations
• Overview of common application servers
• Atomic File Transactions.
• Atomic File Transactions, Part 2
• MIDP memory tuning
• Design patterns catalog
• EJB design
• Design Patterns
• J2EE Design Patterns for the presentation tier
• Thread programming
• Command objects for RMI.
• Caching RMI stubs.
• Website performance.
• Mobile & wireless devices
• Discussion on JDBC performance
• Improving J2EE performance
• An assortment of tips
• Avoiding synchronization deadlocks
• Performance tuning
• Why CMP is better than BMP
• Scalable recoverable applications
• Techniques to avoid deadlocks
• Alternatives to using 'new'.
• Load testing of web applications
• J2EE design patterns to improve performance
• Oracle JDBC tips
• Chapter 19, "Performance" of Java Programming with Oracle JDBC
• Database performance
• JDBC tutorial (requires free registration)
• Performance optimizing design patterns for J2EE
• Article on recycling resource pools
• Article on building an object pool for improved performance.
• Optimizing JDBC
• EJB performance tips
• JDBC performance tips
• Servlet performance tips
• High load web servlets
• JSP performance tips
• JMS performance tips
• Pattern performance tips
• Writing a seamless audio looper
• The Verified Service Locator pattern
• Sun Community chat on Java BluePrints
• Clustering with JBoss
• Swing performance tips
• Web application scalability.
• Performance chapter (chapter 20) from "Professional JSP 2nd Edition"
• Chapter 3 of "High Performance Java Computing : Multi-Threaded and Networked Programming", "Race Conditions and Mutual Exclusion"
• Chapter 4 of "High Performance Java Computing : Multi-Threaded and Networked Programming", "Monitors"
• Designing Java Performance: reducing object creation
• Expiring cached data
• J2ME game building
• Email summarizing best practices for Promoting Scalable Web Services
• Object Resource Pooling
• Using NIO
• J2EE best practices.
• MIDP GUI programming
• Scaling SOAP-based web services.
• Rules and Patterns for Session Facades
• EJBs are wonderful
• EJB performance tips
• RMI performance tuning
• Local entity beans
• Chapter 1 of "Enterprise Java Performance", "Performance in General"
• Chapter 4 of "Enterprise Java Performance", "Local/Remote Issues".
• Peter Haggar's Practical Java Programming Language Guide.
• Performance tuning embedded Java
• J2EE challenges
• J2EE Application servers
• The Optimistic Locking pattern
• Object recycling part 2
• Animation in java applets article
• Another tutorial from Sun
• Basic animation tutorial
• Moving from JSP to EJB
• Judging various aspects of Java, including performance
• Various performance tips from a JavaOne 1998 presentation.
• Load Balancing Web Applications
• Article on using CachedRowSet, a ResultSet that doesn't need continuous connection to the database
• Finalizers
• JMS & JCACHE
• Pseudo Sessions for JSP, Servlets and HTTP
• Clustering for J2EE and Java application servers
• Multicasting efficiency
• Porting to KVM
• BigDecimal and Enumerations
• Using VolatileImage
• Sun community chat session on "Optimizing Java Program Performance" with Peter Haggar.
• Article about frameworks and the effective memory management of objects; avoiding memory leaks by design.
• Various strategies for connecting to databases
• Object creation tuning
• The java
• Chapter 1, "What Is Performance?" of "Java Platform Performance".
• Chapter 2, "The Performance Process" of "Java Platform Performance".
• Chapter 5, "RAM Footprint" of "Java Platform Performance: Strategies and Tactics
• Chapter 6, "Controlling Class Loading" of "Java Platform Performance: Strategies and Tactics
• Chapter 7, "Object Mutability: Strings and other things" of "Java Platform Performance: Strategies and Tactics
• Chapter 8, "Algorithms and data structures" of "Java Platform Performance: Strategies and Tactics
• Chapter 10 (Swing models and renderers) of "Java Platform Performance: Strategies and Tactics
• Server performance testing
• Optimizing entity beans
• EJB best practices
• J2EE clustering
• Parallel clustering of machines using Java
• Speeding up file searching in JFileChooser
• "EJB2 clustering with application servers"
• Typesafe Enumeration gotchas
• RMI arguments
• JViewport scrolling performance
• Servlet 2.3 events
• Sun presentation on J2SE performance strategies
• Javabean component architecture
• Introductory level article on threading applets
• J2EE design optimizations
• Choosing a J2EE application server, emphasizing the importance of performance issues
• Implementing clustering on a J2EE web server (JBoss+Jetty)
• Making HTTP connections using background threads.
• Anonymous inner classes
• Scaling web services
• Timers and low-level GUI display effects
• Architecting and Designing Scalable, Multitier Systems
• Optimizing dynamic web pages
• J2ME apps, with a discussion of the needs to balance performance
• Creating Web-based, interactive graphics.
• The Proxy design pattern.
• Stateful vs Stateless EJBs
• Webservices SOAP communications overheads
• Sun community chat session on "Threading and Concurrency in the Java Platform" with Thomas Christopher and George Thiruvathukal
• Customized high-speed, fine-grained access control
• Deciding whether EJB is appropriate.
• Rambling discussion of building J
• Tuning tips intended for Sun's "Web Server" product, but actually generally applicable.
• JMS & CORBA
• Paul Tyma's article on low level Java optimizations.
• Improving applet download time by installing the applet on the client.
• Developing Scalable Distributed Applications
• Article on high availability architecture

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

http://www.onjava.com/pub/a/onjava/2001/02/22/optimization.html
Performance planning for managers (Page last updated February 2001, Added 2001-03-21, Author Jack Shirazi, Publisher OnJava). Tips:

• Include a performance focus in the analysis.
• Require performance predictions from the design.

http://java.oreilly.com/news/jptsummary_1100.html
ftp://ftp.ora.com/pub/examples/java/javapt/summary.html
A high level overview of technical performance tuning, covering 5 levels of tuning competence. (Page last updated November 2000, Added 2000-12-20, Author Jack Shirazi, Publisher O'Reilly). Tips:

• Architecture bottlenecks are often easy to spot: they are the connecting lines on the diagrams; the single threaded components; the components with many connecting lines attached; etc.
• After targeting design and architecture, the biggest bang for your buck in terms of improving performance is choosing a better VM, and then choosing a better compiler.

http://www.oreilly.com/catalog/javapt/chapter/ch04.html
Chapter 4 of "Java Performance Tuning", "Object Creation". (Page last updated September 2000, Added 2000-10-23, Author Jack Shirazi, Publisher O'Reilly). Tips:

• Define methods that accept reusable objects to be filled in with data, rather than methods that return objects holding that data. (Or you can return immutable objects.)
• Canonicalize objects wherever possible. Compare canonicalized objects by identity. [Canonicalizing objects means having only a single reference of an object, with no copies possible].
• Create only the number of objects a class logically needs (if that is a small number of objects).
• Replace strings and other objects with integer constants. Compare these integers by identity.
• Use methods that alter objects directly without making copies.
• Create or use specific classes that handle primitive data types rather than wrapping the primitive data types.
• Keep constructors simple and inheritance hierarchies shallow.
• Eliminate object-creation bottlenecks by moving object creation to an alternative time.
• Create objects early, when there is spare time in the application, and hold those objects until required.
• Use lazy initialization when there are objects or variables that may never be used, or when you need to distribute the load of creating objects.
• Use lazy initialization only when there is a defined merit in the design, or when identifying a bottleneck which is alleviated using lazy initialization.

http://www.onjava.com/pub/a/onjava/2001/09/25/optimization.html
Multiprocess JVMs (Page last updated September 2001, Added 2001-10-22, Author Jack Shirazi, Publisher OnJava). Tips:

• Using or implementing a multiprocess framework to combine Java processes into one JVM can save on memory space overheads and reduce startup time.

http://www.onjava.com/pub/a/onjava/2001/12/05/optimization.html
Measuring JDBC performance (Page last updated December 2001, Added 2001-12-26, Author Jack Shirazi, Publisher OnJava). Tips:

• [Article discusses how to create JDBC wrapers to measure the performance of database calls].
• JDBC wrappers are simple and robust, and require very little alteration to the application using them (i.e, are low maintenance), so they are suitable to be retained within a deployed application.

http://www.onjava.com/pub/a/onjava/2001/08/22/optimization.html
Catching OutOfMemoryErrors (Page last updated August 2001, Added 2001-10-22, Author Jack Shirazi, Publisher OnJava). Tips:

• If a process gets too large, the operating system will start paging the process causing a severe decrease in performance.
• It is reasonable to catch the OutOfMemoryError if you can restore your application to a known state that can proceed with processing. For example, daemon service threads can often do this.

http://www.cs.berkeley.edu/~mdw/proj/java-nbio/
Whoopee!! A non-blocking I/O library for Java. This is the single most important functionality missing from the SDK for scalable server applications. The important class is SelectSet which allows you to multiplex all your i/o streams. If you want a scalable server and can use this class then DO SO. NOTE THAT SDK 1.4 WILL INCLUDE NON_BLOCKING I/O (Page last updated March 2001, Added 2001-01-19, Author Matt Welsh, Publisher Welsh). Tips:

• [The system select(2)/poll(2) functions allow you to take any collection of i/o streams and ask the operating system to check whether any of them can execute read/write/accept without blocking. The system call will block if requested until any one of the i/o streams is ready to execute. Before Java, no self-respecting server would sit on multiple threads in blocked i/o mode, wasting thread resources: instead select/poll would have been used.]

http://www.cs.cmu.edu/~jch/java/optimization.html
For years, Jonathan Hardwick's old but classic site was the only coherent Java performance tuning site on the web. He built it while doing his PhD. It wasn't updated beyond March 1998, when he moved to Microsoft, but most tips are still useful and valid. The URL is for the top page, there are another eight pages. Thanks Jonathan. (Page last updated March 1998, Added 2000-10-23, Author Jonathan Hardwick, Publisher Hardwick). Tips:

• Don't optimize as you go. Write your program concentrating on clean, correct, and understandable code.
• Replace the generic standard classes with faster implementations specific to the application.
• Avoid expensive constructs and data structures, e.g. one-dimensional array is faster than a two-dimensional array.

http://www.ddjembedded.com/resources/articles/2001/0112g/0112g.htm
Balancing Network Load with Priority Queues (Page last updated December 2001, Added 2002-02-22, Author Frank Fabian, Publisher Dr. Dobb's). Tips:

• Hardware traffic managers redirect user requests to a farm of servers based on server availability, IP address, or port number. All traffic is routed to the load balancer, then requests are fanned out to servers based on the balancing algorithm.
• Popular load-balancing algorithms include: server availability (find a server with available processing capability); IP address management (route to the nearest server by IP address); port number (locate different types of servers on different machines, and route by port number); HTTP header checking (route by URI or cookie, etc).
• Web hits should cater for handling peak hit rate, not the average rate.
• You can model hit rates using gaussian distribution to determine the average hit rate per time unit (e.g. per second) at peak usage, then a poisson probability gives the probability of a given number of users simulatneously hitting the server within that time unit. [Article gives an example with gaussian fitted to peak traffic of 4000 users with a standard deviation of 20 minutes resulting in an average of 1.33 users per second at the peak, which in turn gives the probabilities that 0, 1, 2, 3, 4, 5, 6 users hitting the server within one second as 26%, 35%, 23%, 10%, 3%, 1%, 0.2%. Service time was 53 milliseconds, which means that the server can service 19 hits per second without the service rate requiring requests being queued.]
• System throughput is the arrival rate divided by the service rate. If the ratio becomes greater than one, requests exceed the system capability and will be lost or need to be queued.
• If requests are queued because capacity is exceeded, the throughput must drop sufficiently to handle the queued requests or the system will fail (the service rate must increase or arrival rate decrease). If the average throughput exceeds 1, then the system will fail.
• Sort incoming requests into different priority queues, and service the requests according to the priorities assigned to each queue. [Article gives the example where combining user and automatic requests in one queue can result in a worst case user wait of 3.5 minutes, as opposed to less than 0.1 seconds if priority queues are used].
• [Note that Java application servers often do not show a constant service time. Instead the service time often increases with higher concurrency due to non-linear effects of garbage collection].

http://library.cs.tuiasi.ro/programming/java/cutting_edge_java_game_programming/ewtoc.html
"Cutting Edge Java Game Programming". Oldish but still useful intro book to games programming using Java. (Page last updated 1996, Added 2001-06-18, Author Neil Bartlett, Steve Simkin , Publisher Coriolis). Tips:

• AWT components are not useful as game actors (sprites) as they do not overlap well, nor are they good at being moved around the screen.
• Make sure you have a throttle control that can make the game run slower (or pause) when necessary.
• If the cumulative downloading of your applet exceeds the player?s patience, you?ve lost a customer.
• The user interface should always be responsive. A non-responsive window means you will lose your players. Give feedback on necessary delays. Provide distractions when unavoidable delays will be lengthy [more than a few seconds].
• Latency between networked players can easily lead to de-synchronized action and player frustration. Displays should locally simulate remote action as continuing current activities/motions, until the display is updated. On update, the actual current situation should be smoothly resolved with the simulated current situation.
• Sending activity updates more frequently ensures smoother play and better synchronization between networked players, but requires more CPU effort and so affects the local display. In order to avoid adversely affecting local displays, send actvity updates from a low priority thread.
• It is usually possible to increase performance at the expense of image quality and accuracy. Techniques include reducing pixel depth or display resolution, field interlacing, aliasing. The key, however, is to degrade the image in a way that is likely to be undetectable or unnoticeable to the user. For example a moving player often pays less attention to image quality than a resting or static player.

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.glenmccl.com/jperf/
Glen McCluskey's paper with 30 tuning tips, now free. (Page last updated October 1999, Added 2000-10-23, Author Glen McCluskey, Publisher McCluskey). Tips:

• Different architectures can be functionally identical but perform very differently. Keep performance in mind at the design stage.
• Use static variables for fields that only need to be assigned once.
• Program using interfaces so that the actual structure can be easily swapped to improve performance.

http://www.javareport.com/html/from_pages/article.asp?id=252
Detailed article on load testing systems (Page last updated January 2001, Added 2001-01-19, Author Himanshu Bhatt, Publisher Java Report). Tips:

• Initially you should identify the probable performance and scalability based on the requirements. You should be asking about: numbers of users/components; component interactions; throughput and transaction rates; performance requirements.
• Factor in batch requirements and performance characteristics of dependent (sub)systems. Note that additional layers, like security, add overheads to performance.

http://www.as400.ibm.com/developer/java/topics/jdbctips.html
JDBC Performance Tips (targeted at AS/400, but generically applicable) (Page last updated February 2001, Added 2001-03-21, Authors Richard Dettinger and Mark Megerian, Publisher IBM). Tips:

• If you are not using stored procedures or triggers, turn off autocommit. All transaction levels operate faster with autocommit turned off, and doing this means you must code commits. Coding commits while leaving autocommit on will result in extra commits being done for every db operation.
• Use the appropriate transaction level. Increasing performance costs for transaction levels are: TRANSACTION_NONE; TRANSACTION_READ_UNCOMMITTED; TRANSACTION_READ_COMMITTED; TRANSACTION_REPEATABLE_READ; TRANSACTION_SERIALIZABLE. Note that TRANSACTION_NONE, with autocommit set to true gives access to triggers, stored procedures, and large object columns.
• Store string and char data as Unicode (two-byte characters) in the database.
• Use batch updates (sending multiple rows to the database in one call).

http://www.patrick.net/jpt/index.html
Patrick Killelea's Java performance tips. (Page last updated 1999, Added 2000-10-23, Author Patrick Killelea, Publisher Killelea). Tips:

• The architecture and algorithms of your program are much more important than any low-level optimizations you might perform.
• Keep small inheritance chains.
• Merge classes.
• Accessor methods increase overhead.
• Use UDP rather than TCP if speed is more important than accuracy.
• Use threads. Prioritize threads. Use notify instead of notifyAll. Use synchronization sparingly.
• Keep the paint method small. It will get called a lot.

http://java.sun.com/docs/books/tutorial/extra/fullscreen/
Tutorial on the full screen capabilities in the 1.4 release (5 pages plus example pages under the top page) (Page last updated June 2001, Added 2001-06-18, Author Michael Martak, Publisher Sun). Tips:

• Don't define the screen painting code in the paint() method called by the AWT thread. Define your own rendering loop for screen drawing, to be executed in any thread other than the AWT thread.
• Do not rely on the update or repaint methods for delivering paint events.

http://www.devresource.hp.com/JavaATC/JavaPerfTune/index.html
HP Java tuning site, including optimizing Java and optimizing HPUX for Java. This is the top page, but several useful pages lie off it (tips extracted for inclusion below). Includes a nice "procedure" list for tuning apps, and some useful forms for what you should record while tuning. (Page last updated 2000, Added 2000-10-23, Author ?, Publisher HP). Tips:

• Consider architecture and components for bottlenecks.
• Third-party components may have options that cause bottlenecks.
• Watch out for bottlenecks introduced from third party products. Make sure you know and use the options available, many of which can affect performance (for better or worse). Document the changes you make so that you will be able to reproduce the performance.
• computationally intensive applications should increase the number of CPUs to increase overall system performance and throughput.

http://www.sys-con.com/java/article.cfm?id=671
J2EE Application server performance (Page last updated April 2001, Added 2001-04-20, Author Misha Davidson, Publisher Java Developers Journal). Tips:

• Good performance has sub-second latency (response time) and hundreds of (e-commerce) transactions per second.
• Avoid n-way database joins: every join has a multiplicative effect on the amount of work the database has to do. The performance degradation may not be noticeable until large datasets are involved.
• Avoid bringing back thousands of rows of data: this can use a disproportionate amount of resources.
• Avoid using the SingleThreadModel interface for servlets: write thread-safe code instead.
• Excessive use of custom tags may create unnecessary processing overhead.
• Using multiple levels of BodyTags combined with iteration will likely slow down the processing of the page significantly.
• Use optimistic transactions: write to the database while checking that new data is not be overwritten by using WHERE clauses containing the old data. However note that optimistic transactions can lead to worse performance if many transactions fail.
• For read-only queries involving large amounts of data, avoid EJB objects and use JavaBeans as an intermediary to access manipulate and store the data for JSP access.
• Use stateless session EJBs to cache and manage infrequently changed data. Update the EJB occasionally.
• Use a dedicated session bean to perform and cache all JNDI lookups in a minimum number of requests.
• Minimize interprocess communication.
• Use clustering (multiple servers) to increase scalability.

http://developer.java.sun.com/developer/technicalArticles/ebeans/ejbperformance/
Designing Entity Beans for Improved Performance (Page last updated March 2001, Added 2001-03-21, Author Beth Stearns, Publisher Sun). Tips:

• Remember that every call of an entity bean method is potentially a remote call.
• Designing with one access method per data attribute should only be used where remote access will not occur, i.e. entities are guaranteed to be in the same container.
• Use a value object which encapsulates all of an entity's data attributes, and which transfers all the data in one network transfer. This may result in large objects being transferred though.
• Group entity bean data attributes in subsets, and use multiple value objects to provide remote access to those subsets.

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:

• Try to optimize the design first before targeting the implementation.
• Specify performance in the project requirements, and specify seperate performance requirements for the various layers of the application.
• Consider the effects of performance at the analysis stage, and include testing of 3rd party tools.
• Design in asynchronous operations so tasks are not waiting for others to finish when they don't need to.
• avoid remote method calls
• use callbacks to avoid blocking remote method calls
• use batching for remote method calls
• use the flyweight pattern to reduce object creation [The flyweight pattern uses a factory instead of 'new' to reuse objects rather than always create new ones].
• use shallow hierarchies (to avoid long instantiation chains)
• mix model with view (not recommended, breaks OO)
• use multiple threads to increase perceived performance

http://java.sun.com/features/2002/03/swinggui.html
Accelerating GUI apps (after 1.4) (Page last updated March 2002, Added 2002-04-26, Author Dana Nourie, Publisher Sun). Tips:

• Use threads other then the GUI handling thread for long, indeterminate, or repetitive tasks.

http://www.javaworld.com/javaworld/jw-09-1996/jw-09-indepth.html
Article about avoiding creating objects where possible. (Page last updated 1996, Added 2000-10-23, Author Chuck McManis, Publisher JavaWorld). Tips:

• Simple designs can easily run through many unnecessary objects, e.g. data wrapper objects like Integer.

http://java.sun.com/people/jag/Fallacies.html
The Eight Fallacies of Distributed Computing (Page last updated 2000, Added 2002-03-25, Author Peter Deutsch, Publisher Sun). Tips:

• The network can fail to deliver at any time.
• Latency is significant.
• Bandwidth is always limited.

http://www.javaworld.com/javaworld/jw-01-2001/jw-0112-performance.html
Article on designing for performance focusing on interfaces (Page last updated January 2001, Added 2001-02-21, Author Brian Goetz, Publisher JavaWorld). Tips:

• Avoid excessive object creation: be wary of object creation inside of tight loops when executing performance-critical code.
• Performance-conscious programmers avoid excessive use of String.
• Defining a utility class which is applied to data required by its constructor means that you must create a new object for every piece of data to run it on. Instead, do not require data in the constructor.
• Do not force methods to provide arguments with input in the form that is convenient rather than efficient. For example, don't require that arguments be passed only as String objects if a byte array or char array would also be functionally equivalent (try to support all formats, especially the efficient ones).
• Defining a method signature in terms of an interchange type (the type of object passed from a caller method to the callee method as an argument) reduces the interface's complexity while maintaining its flexibility, but sometimes this simplicity comes at the cost of performance.

http://java.sun.com/docs/hotspot/PerformanceFAQ.html
HotSpot FAQ (Page last updated August 2000, Added 2001-02-21, Author ?, Publisher Sun). Tips:

• Sun recommends you no longer use objects pools [this is rather a sweeping and inappropriate statement. Object pools are still useful even with HotSpot, but presumably not as often as previously].

http://www.unixsolutions.hp.com/products/java/perf.html
A different HP tip page on optimizing Java performance, from the "HP-UX Programmer's Guide for Java". Gives info on HP system performance monitoring too (Page last updated ?, Added 2000-10-23, Author ?, Publisher HP). Tips:

• Maximize thread lifetimes and minimize thread creation/destruction cycles.
• Minimize contention for shared resources.
• Complex AWT graphics will slow down your performance.

http://www.artima.com/designtechniques/hotspot.html
Bill Venners on "the right way to optimize" (Page last updated May 1998, Added 2000-10-23, Author Bill Venners, Publisher Artima). Tips:

• Only as a last resort should you sacrifice good object-oriented, thread-safe design and maintainable code in the name of performance.

http://www.informit.com/content/index.asp?product_id={11E331A5-5A08-4FFD-B018-2A7E24D0359B}
Application performance tuning (Page last updated July 2002, Added 2002-07-24, Author Baya Pavliashvili and Kevin Kline, Publisher informIT). Tips:

• Application performance problems can be caused and mitigated with any combination of the following areas: Network topology and throughput; Server hardware configuration; client application code; middle-tier components; database communication code; database configuration settings; logical and physical database design; operating system settings; client hardware; overall application architecture.
• Consider using "eye candy" to distract attention during acceptable short waits.

http://www.javaworld.com/javaworld/jw-11-1999/jw-11-performance.html
Object management article (Page last updated November 1999, Added 2000-12-20, Author Dennis M. Sosnoski, Publisher JavaWorld). Tips:

• Avoid using wrapper classes (for primitive data types, e.g. Integer) as they impose extra overheads.
• Avoid convenience classes like Point if you can manage the underlying data directly.

http://cin.earthweb.com/public/article/0,,10493_1145241,00.html
Website usability metrics (Page last updated May 2002, Added 2002-07-24, Author Sharon Gaudin, Publisher EarthWeb). Tips:

• A website must be easy to navigate and have a quick display and response time.
• Bad navigation metrics include: abandoned shopping carts; first time visitors look at one or two pages and disappear; dead ends require the "back" button; less than 5% buy something; any broken links.
• Good navigation metrics include: three pages or less from wesbite entry to desired information; no streaming video or Flash introductions; multiple ways to reach the required information; up to date search engines; basic compancy and contact info one click away from the homepage.

http://www-4.ibm.com/software/webservers/appserv/ws_bestpractices.pdf
Paper detailing the "Best Practices for Developing High Performance Web and Enterprise Applications" using IBM's WebSphere. All the tips are generally applicable to servlet/EJB development, as well as other types of server development. (Page last updated September 2000, Added 2001-01-19, Author Harvey W. Gunther, Publisher IBM). Tips:

• Do not store large object graphs in javax.servlet.http.HttpSession. Servlets may need to serialize and deserialize HttpSession objects for persistent sessions, and making them large produces a large serialization overhead.
• Do not use javax.servlet.SingleThreadModel.
• Access entity beans from session beans, not from client or servlet code.
• The EJB "remote programming" model always assumes EJB calls are remote, even where this is not so. Where calls are actually local to the same JVM, try to use calling mechanisms that avoid the remote call.

http://www-4.ibm.com/software/webservers/appserv/3steps_perf_tuning.pdf
Tuning IBM's WebSphere product. White paper: "Methodology for Production Performance Tuning". Only non-product specific Java tips have been extracted here. (Page last updated September 2000, Added 2001-01-19, Author Gennaro (Jerry) Cuomo, Publisher IBM). Tips:

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

http://www-106.ibm.com/developerworks/java/library/j-threads1.html
When synchronization is required (Page last updated July 2001, Added 2001-07-20, Author Brian Goetz, Publisher IBM). Tips:

• Too little synchronization can lead to corrupt data; too much can lead to reduced performance and deadlock.
• Composite operations may need synchronizing to make them atomic even if each individual operation is already synchronized.

http://www.onjava.com/pub/a/onjava/2002/04/03/javaenterprise_tips.html
J2EE worst practices (Page last updated April 2002, Added 2002-04-26, Author Brett McLaughlin, Publisher OnJava). Tips:

• The choice of data store type (RDB, ODB, XML-DB, directory-server, etc) affects performance, and should not be made without performance considerations.
• Directory servers are optimized for frequent reads, with few writes. If you frequently add data to a directory server, performance degrades.
• Stateless session beans are soooo much faster.

http://www.weblogic.com/docs51/admindocs/tuning.html
Weblogic tuning (generally applicable Java tips extracted) (Page last updated June 2000, Added 2001-03-21, Author BEA Systems, Publisher BEA). Tips:

• Response time is affected by: contention and wait times, particularly for shared resources; and software and hardware component performance, i.e. the amount of time that resources are needed.
• A well-designed application can increase performance by simply adding more resources (for instance, an extra server).
• Too many threads causes too much context switching. Too few threads may underutilize the system. If n=number of threads, k=number of CPUs, then: (n < k) results in an under utilized CPU; (n == k) is theoretically ideal, but each CPU will probably be under utilized; (n > k) by a "moderate amount of threads" is practically ideal; (n > k) by "many threads" can lead to significant performance degradation from context switching. Blocked threads count for less in the previous formulae.

http://www.weblogic.com/docs51/techdeploy/jdbcperf.html
Weblogic JDBC tuning (Page last updated April 1999, Added 2001-03-21, Author BEA Systems, Publisher BEA). Tips:

• Avoid moving data unless absolutely necessary. Process the data and produce results as close to its source as possible. Use stored procedures.
• Use built-in DBMS set-based processing to operate on multiple rows/tables in one request.
• Avoid row at a time processing, process multiple rows together wherever possible.
• Proper use of SQL can reduce resource requirements. Use queries which return the minimum of data needed: avoid SELECT * queries. A complex query that returns a small subset of data is more efficient than a simple query that returns more data than is needed.
• Never let a DBMS transaction span user input.
• Consider using optimistic locking. Optimistic locking employs timestamps to verify that data has not been changed by another user, otherwise the transaction fails.
• Use in-place updates, i.e. change data in rows/tables that already exist rather than adding or deleting rows/tables. Try to avoid moving rows or changing their sizes.
• Store operational data and historic data separately (or more generally store frequently used data separately from infrequently used data).
• DBMSs work well with parallelism. Try to design the application to do other things while interacting with the DBMS.
• Use pipelining and parallelism. Designing applications to support lots of parallel processes working on easily distinguished subsets of the work makes the application faster. If there are multiple steps to processing, try to design your application so that subsequent steps can start working on the portion of data that any prior process has finished, instead of having to wait until the prior process is complete.

http://www.sys-con.com/websphere/article.cfm?id=40
JDBC optimizing for DB2 (Page last updated April 2002, Added 2002-04-26, Author John Goodson, Publisher WebSphere Developers Journal). Tips:

• Use the same connection to execute multiple statements.
• Keep connection objects open, and reuse them, rather than repeatedly connecting and disconnecting.
• Use the most efficiently handled data type: character strings are faster than integers, which are in turn more efficient than floating-point and timestamps.

http://www.sys-con.com/java/article.cfm?id=1171
J2EE Performance tuning (Page last updated October 2001, Added 2001-10-22, Author James McGovern, Publisher Java Developers Journal). Tips:

• Always access entity beans from session beans.
• If only using an entity bean for data access, use JDBC directly instead.
• Use local entity beans when beans are co-located in the same JVM.
• Use a dedicated remote object to generate unique primary keys.
• Consider storing all database character data in Unicode to eliminate conversion overheads. But beware: this step will cause your database size to grow, as Unicode requires 2 bytes per character.
• Use block fetches when the query will give a large ResultSet and all rows are needed. Use the Page-by-Page Iterator pattern when only some of the rows may be needed.
• Consider using an in-memory database (product) for data that doesn't need to be persisted.
• Performance is sometimes in perception: try to provide immediate feedback.

http://www.javaworld.com/javaworld/jw-09-2001/jw-0907-merlin.html
Using nonblocking I/O and memory-mapped buffers in SDK 1.4. (Page last updated September 2001, Added 2001-10-22, Author Michael T. Nygard, Publisher JavaWorld). Tips:

• Many threads each blocked on i/o is an inefficient architecture in comparison to one thread blocked on many i/o calls (multiplexed i/o).
• Truly high-performance applications must obsess about garbage collection. The more garbage generated, the lower the application throughput.
• Use Selectors to multiplex i/o and avoid having to block multiple threads waiting on i/o.

http://www.sys-con.com/java/article.cfm?id=1408
Combining apps in one JVM (Page last updated April 2002, Added 2002-04-26, Author Kirk Pepperdine, Publisher Java Developers Journal). Tips:

• Loading multiple applications in the same JVM allows resource sharing and reduce system memory requirements.
• Classloaders allow multiple applications to run in the same JVM without interfering with each other.
• [Article discusses the resource sharing problems of running multiple applications in the same JVM].

http://www.AmbySoft.com/javaCodingStandards.pdf
Coding standards with a small but interesting section (section 7.3) on optimizations (Page last updated January 2000, Added 2001-04-20, Author Scott Ambler, Publisher AmbySoft). Tips:

• Users are sensitive to particular delays: users will likely be happier with a screen that draws itself immediately and then takes eight seconds to load data than with a screen that draws itself after taking five seconds to load data.
• Give users immediate feedback: you do not always need to make your code run faster to optimize it in the eyes of your users.
• Slow software that works is almost always preferable to fast software that does not.

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:

• Load balancing: random; minimum load; round-robin; weighted round-robin; performance-based; load-based; dynamic algorithm based; dynamic registration.
• Optimistic transaction support.

http://www.onjava.com/pub/a/onjava/2001/11/07/atomic.html
Atomic File Transactions. (Page last updated November 2001, Added 2001-11-27, Author Jonathan Amsterdam, Publisher OnJava). Tips:

• If you don't require powerful search capabilities, using flat files may be faster than dealing with a database.
• Basic file operations (deletion, creation, renaming) are atomic. Other operations and combinations of operations are not atomic. Atomicity can be built but comes at a performance cost. You will have to determine whether the increase in robustness is worth the slowdown in your application.
• Do the I/O in a background thread to mitigate the performance impact of adding atomicity to file transactions.
• [Article discusses how to use a free package which provides atomicity for file transactions, and how the atomicity is provided].

http://www.onjava.com/pub/a/onjava/2002/02/06/atomic.html
Atomic File Transactions, Part 2 (Page last updated February 2002, Added 2002-02-22, Author Jonathan Amsterdam, Publisher OnJava). Tips:

• [Article continues implementation of a framework for atomic file transactions].

http://wireless.java.sun.com/midp/ttips/memory/
MIDP memory tuning (Page last updated June 2002, Added 2002-07-24, Author Jonathan Knudsen, Publisher Sun). Tips:

• Catch OutOfMemoryErrors on all allocations, or at least the large ones. Don't let an OutOfMemoryError take your application by surprise.
• MIDlets use three types of memory: program memory, heap, and persistent storage. Each of these may be scarce and they should all be treated with respect.

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:

• [Page lists some patterns with summaries and links to detailed info. Patterns are: Data Access Object; Fast-Lane Reader; Front Controller; Page-by-Page Iterator; Session Facade; Value Object].
• Use the Data Access Object pattern to decouple business logic from data access logic, allowing for optimizations to be made in how data is managed.
• Use the Fast-Lane Reader pattern to accelerate read-only data access by not using enterprise beans.
• Use the Front Controller pattern to centralize incoming client requests, allowing optimizations to be made in aggregating the resulting view.
• Use the Page-by-Page Iterator pattern to efficiently access a large, remote list by retrieving its elements one sublist of value objects at a time.
• Use the Session Facade pattern to provide a unified, workflow-oriented interface to a set of enterprise beans, thus minimizing client calls to server EJBs.
• 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.
• Low granularity (i.e. fine-grained) methods in an EJB typically leads to poor performance of the overall system.
• 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.
• The most effective way to improve the overall performance of EJB-based applications is to minimize the amount of method invocations, making the communications overhead negligible compared with the execution time. This can be achieved by implementing coarse-grained methods.
• Entity beans should not be simply mapped to database tables. Treating entity beans as such fine-grained objects which are effectively wrappers on table rows leads to increased network communications and heavier database communications than if entity beans are treated as coarse-grained components.
• For optimal performance, entity beans should be designed to: have large granularity, which usually means they should contain multiple Java classes and support multiple database tables; be associated with a certain amount of persistent data, typically multiple database tables, one of which should define the primary key for the whole bean; support meaningful business methods and encapsulate business rules to access the data.
• Don't use client transactions in the EJB environment since long-running transactions that can cause database lockup.
• Entity beans are transactional resources due to their stateful nature, but application server vendors often rely on the underlying database to lock and resolve access appropriately. Although this approach greatly improves performance, it provides the potential for database lockup.

http://developer.java.sun.com/developer/technicalArticles/J2EE/despat/
Design Patterns (Page last updated January 2002, Added 2002-01-25, Author Vijay Ramachandran, Publisher Sun). Tips:

• [Article discusses several design patterns: Model-View-Controller, Front Controller, Session Facade, Data Access Object].
• Use the Front Controller pattern to channel all client requests through a single decision point, which allows the application to be balanced at runtime.
• Use a Session Facade to provide a simple interface to a complex subsystem of enterprise beans, and to reduce network communication requirements.
• Use Data Access Objects to decouple the business logic from the data access logic, allowing data access optimizations to be decoupled from other types of optimizations.

http://www.onjava.com/pub/a/onjava/2002/01/16/patterns.html
J2EE Design Patterns for the presentation tier (Page last updated January 2002, Added 2002-01-25, Author Sue Spielman, Publisher OnJava). Tips:

• [Article discusses several design patterns: Intercepting Filter, Front Controller, View Helper, Composite View, Service To Worker, Dispatch View. Performance is not explicitly covered, but at least a couple are relevant to getting good performance].

http://www.devx.com/upload/free/Features/Javapro/2002/02feb02/kr0202/kr0202-1.asp
Thread programming (Page last updated January 2002, Added 2002-01-25, Author Karthik Rangaraju, Publisher DevX). Tips:

• Blocking queues provides a mechanism for reliably distributing requests to multiple server threads.
• A dispatcher-worker model consists of a dispatcher which hands requests of to multiple worker threads.
• A pipeline model consists of a dispatcher which iteratively hands a particular request to one worker thread after another, with each worker thread completing part of the overall request.

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://intranetjournal.com/articles/200110/gb_10_24_01a.html
Website performance. (Page last updated October 2001, Added 2001-11-27, Author Gordon Benett, Publisher Intranet Journal). Tips:

• Some e-commerce consultants cite an attention span on the order of eight seconds as the threshold for abandoning a slow retail site.
• Where broadband connections are the norm, pages that don't appear instantly stand a good chance of never being seen: slow pages might as well be no pages.
• Systems can only be designed to meet performance goals if those goals have been identified. Determine what range of response times will be acceptable.
• Try to understand the performance impacts of your design decisions. However the performance of some design choices can be hard to predict and may remain unclear before testing.
• Try to plan up-front rather than have to rely on late-phase tuning.

http://www.sys-con.com/java/article.cfm?id=1412
Mobile & wireless devices (Page last updated April 2002, Added 2002-04-26, Author James White, Publisher Java Developers Journal). Tips:

• Prototype to determine the performance of your device. Wireless transmissions require testing to determine if the transfer rates and processing times are acceptable.
• Attempt to create applications that can accomplish 80% or more of their operations through the touch of a single key/button or the "tap" or touch of the stylus to the screen.
• Trying to manipulate a very small scroll bar on a small screen can be an exercise in hand-eye coordination. Horizontal scrolling should be avoided at all costs. Use "jump-to" buttons rather than scrollbars.
• Try to avoid having the user remember any data, or worse, having to compare data across screens.
• Avoid garbage generation: Use StringBuffer for mutable strings; Pool reusable instances of objects like DateFormat; Use System.gc() to jump-start or push the garbage collection process.
• Avoid deep hierarchies in your class structure.

http://www.jguru.com/jguru/faq/view.jsp?EID=131579
Discussion on JDBC performance (Page last updated August 2000, Added 2001-02-21, Author , Publisher JGuru). Tips:

• Use the most appropriate datatype specific kinds of data, e.g. store dates as a date type rather than varchar.

http://www.theserverside.com/resources/article.jsp?l=J2EEPerformance
Improving J2EE performance (Page last updated May 2002, Added 2002-07-24, Author Scott Marlow, Publisher The Server Side). Tips:

• If supporting clients with slow connections, consider compressing data for network communication.
• Minimize the number of network round trips required by the application.
• For applications to scale to many users, minimize the amount of shared memory that requires updating.
• For optimum performance, zero shared memory provides a cache per user.

http://jsl.jcon.org/javaperformance.html
An assortment of tips (Page last updated 2000, Added 2000-10-23, Author Curt Smith, Publisher Smith). Tips:

• Polling is only acceptable when waiting for outside events and should be performed in a "side" thread. Use wait/notify instead.

http://www.javaworld.com/javaworld/jw-10-2001/jw-1012-deadlock.html
Avoiding synchronization deadlocks (Page last updated October 2001, Added 2001-10-22, Author Brain Goetz, Publisher JavaWorld). Tips:

• Always acquire locks in the same order to avoid one common cause of deadlocking. If you can guarantee that all locks will always be acquired in a consistent order, then your program will not deadlock.

http://www.sys-con.com/java/article.cfm?id=1149
Performance tuning (Page last updated September 2001, Added 2001-10-22, Author James McGovern, Publisher Java Developers Journal). Tips:

• Often there's a trade-off between designing for reuse and designing for performance. Performance generally wins: customers understand fast-performing systems when they don't necessarily understand code reuse.
• Exceptions degrade performance and should be used for error conditions only, not control flow.
• Use the factory pattern to enable reuse or cloning of objects.
• Use non-blocking I/O (available from 1.4, or use www.cs.berkeley.edu/~mdw/proj/java-nbio/download.html for earlier versions).
• Create/Use method interfaces that reduce overhead.
• Avoid stateful sessions.

http://www.sys-con.com/weblogic/article.cfm?id=58
Why CMP is better than BMP (Page last updated April 2002, Added 2002-04-26, Author Tyler Jewell, Publisher Weblogic Developers Journal). Tips:

• Use CMP except in specific cases when BMP is necessary: fields use stored procedures; persistence is not simple JDBC (e.g. JDO); One bean maps to multiple tables; non-standard SQL is used.
• CMP can make many optimizations: optimal locking; optimistic transactions; efficient lazy loading; efficiently combining multiple queries to the same table (i.e. multiple beans of the same type can be handled together); optimized multi-row deletion to handle deletion of beans and their dependents.

http://www.theserverside.com/resources/article.jsp?l=Building-Sclable-Recoverable-Applications
Scalable recoverable applications (Page last updated May 2002, Added 2002-07-24, Author Billy Newport, Publisher The Server Side). Tips:

• Split the application into a transactional part and a non-transactional part. The non-transactional part can be replicated.
• Using a single machine limits both reliability and scalability. Scalability is completely dependent on how powerful the single machine can become.
• Multiple front-end machines with http request load balancing is more reliable, but the database machine is still a single point of failure.
• Partitioning the database across multiple machines adds scalability, but must be done with care.
• A load balancing message queue may be needed for a high rate of messages (>500/sec).
• Note that reliable systems should ensure that all duplicated data have no single points of failure in the software or hardware chain behind the data (different controllers, UPSs, etc).

http://www.sys-con.com/java/article.cfm?id=1133
Techniques to avoid deadlocks (Page last updated September 2001, Added 2001-10-22, Author Mark Dykstra, Publisher Java Developers Journal). Tips:

• Always acquire a set of locks in the same set order.
• Don't hold a lock and wait for an event.
• Specify which thread should have access to data at any time.
• Ensure that both access and update to the same variable is synchronized on the same monitor.

http://www.ddj.com/documents/ddj0204a/
Alternatives to using 'new'. (Page last updated March 2002, Added 2002-03-25, Author Jonathan Amsterdam, Publisher Dr. Dobb's). Tips:

• The Singleton pattern and the Flyweight (object factory) pattern are useful to limit numbers of objects of various types and to assist with object reuse and reduce garbage collection.
• Using variables to provide access to limited numbers of objects is efficient, but a maintenance problem if you need to change the object access pattern, for example from a global singleton to a ThreadLocal Singleton.
• A non-static factory method is polymorphic and so provides many advantages over static factory methods.
• The Abstract Factory design pattern uses a single class to create more than one kind of object.
• An alternative to the Flyweight pattern is the Prototype pattern, which allows polymorphic copies of existing objects. The Object.clone() method signature provides support for the Prototype pattern.
• Prototypes are useful when object initialization is expensive, and you anticipate few variations on the initialization parameters. Then you could keep already-initialized objects in a table, and clone an existing object instead of expensively creating a new one from scratch.
• Immutable objects can be returned directly when using Prototyping, avoiding the copying overhead.

http://www.ibm.com/developerworks/java/library/j-load
Load testing of web applications (Page last updated June 2001, Added 2001-06-18, Author Frank Cohen, Publisher IBM). Tips:

• Current Web-application architectures consists many small servers that are accessed through a load balancer, providing a front-end to a powerful database server. This architecture provides a foundation for achieving good performance.

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.onjava.com/pub/a/onjava/2001/12/19/oraclejdbc.html
Oracle JDBC tips (Page last updated December 2001, Added 2001-12-26, Author Donald Bales, Publisher OnJava). Tips:

• Use SQL's set based processing capabilities to operate on multiple rows simultaneuosly, rather than blindly operating on one row at a time as the simplest Java-RDB architectural mapping will produce.

http://www.oreilly.com/catalog/jorajdbc/chapter/ch19.html
Chapter 19, "Performance" of Java Programming with Oracle JDBC (Page last updated December 2001, Added 2001-12-26, Author Donald Bales, Publisher O'Reilly). Tips:

• Performance should be considered at the start of a project.
• Given a simple SQL statement and a stored procedure call that accomplishes the same task, the simple SQL statement will always execute faster because the stored procedure executes the same SQL statement but also has the overhead of the procedure call itself. On the other hand complex tasks requiring several SQL statements can be faster using stored procedures as fewer network trips and data transfers will be needed.

http://www.fawcette.com/javapro/2002_01/magazine/columns/weblication/
Database performance (Page last updated December 2001, Added 2001-12-26, Author Peter Varhol, Publisher JavaPro). Tips:

• Thoughtful page design makes for a better user experience by enabling the application to seem faster than it really is.
• Use the flush method associated with the out object to display static text and graphics on the browser page before the database query returns, to prevent the user from having to look at a blank page for a long time.
• Scaled systems need optimized SQL calls, querying the right amount of data, and displaying pages before the query is complete.

http://www-105.ibm.com/developerworks/education.nsf/java-onlinecourse-bytitle/56A6275393F0BE5786256AFD004DBBB4?OpenDocument
JDBC tutorial (requires free registration) (Page last updated November 2001, Added 2001-12-26, Author Robert J. Brunner, Publisher IBM). Tips:

• The higher the level of transaction protection, the higher the performance penalty. Transaction levels in order of increasing level are: TRANSACTION_NONE, TRANSACTION_READ_UNCOMMITTED, TRANSACTION_READ_COMMITTED, TRANSACTION_REPEATABLE_READ, TRANSACTION_SERIALIZABLE. Use Connection.setTransactionIsolation() to set the desired tansaction level.
• Savepoints (from JDBC3.0) require expensive resources. Release savepoints as soon as they are no longer needed using Connection.releaseSavepoint().

http://developer.java.sun.com/developer/technicalArticles/J2EE/J2EEpatterns/
Performance optimizing design patterns for J2EE (Page last updated December 2001, Added 2001-12-26, Author Vijay Ramachandran, Publisher Sun). Tips:

• For read-only access to a set of data that does not change rapidly, use the Fast Lane Reader pattern which bypasses the EJBs and uses a (possibly non-transactional) data access object which encapsulates access to the data. Use the Fast Lane Reader to read data from the server and display all of them in one shot.
• When you need to access a large remote list of objects, use the Page-by-Page Iterator pattern which sends smaller subsets of the data as requested until the client no longer want any more data. Use the Page-by-Page Iterator to send lists of simple objects from EJBs to clients.
• When the client would request many small data items which would require many remote calls to satisfy, combine the multiple calls into one call which results in a single Value Object which holds all the data required to be transferred. Use the Value Object to send a single coarse-grained object from the server to the client(s).

http://www.javaworld.com/javaworld/javatips/jw-javatip78.html
Article on recycling resource pools (Page last updated 1998, Added 2000-12-20, Authors Philip Bishop and Nigel Warren, Publisher JavaWorld). Tips:

• Use the builder pattern: break the construction of complex objects into a series simpler Builder objects, and a Director object which combines the Builders to form the complex object. Then you can use Recycler (a type of Director) to replace only the broken parts of the complex object, so reducing the amount of objects that need to be recreated.

http://www.javaworld.com/jw-06-1998/jw-06-object-pool.html
Article on building an object pool for improved performance. (Page last updated June 1998, Added 2000-12-20, Author Thomas E. Davis, Publisher JavaWorld). Tips:

• [Article discusses generic pool issues including storage, tracking, and expiration times of pool elements.]

http://www.sys-con.com/java/article.cfm?id=725
Optimizing JDBC (Page last updated August 2001, Added 2001-08-20, Author John Goodson, Publisher Java Developers Journal). Tips:

• Retrieve data as efficiently as possible: Minimize the amount of data returned by the query; Don't make average users pay the same query cost of the users with extensive query requirements; Remember that users seldom want to see too much data in one go; Use setMaxRows(), setMaxFieldSize(), and SetFetchSize(); Decrease the column size; Use the smallest packet size that will meet your needs (if the driver supports packet sizing).

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:

• EJB calls are expensive. A method call from the client could cover all the following: get Home reference from the NamingService (one network round trip); get EJB reference (one or two network roundtrips plus remote creation and initialization of Home and EJB objects); call method and return value on EJB object (two or more network rountrips: client-server and [mutliple] server-db; several costly services used such as transactions, persistence, security, etc; multiple serializations and deserializations).
• If you don't need EJB services for an object, use a plain Java object and not an EJB object.
• Use Local interfaces (from EJB2.0) if you deploy both EJB Client and EJB in the same JVM. (For EJB1.1 based applications, some vendors provide pass-by-reference EJB implementations that work like Local interfaces).
• Wrap multiple entity beans in a session bean to change multiple EJB remote calls into one session bean remote call and several local calls (pattern called SessionFacade).
• Change multiple remote method calls into one remote method call with all the data combined into a parameter object.
• Cache EJBHome references to avoid JNDI lookup overhead (pattern called ServiceLocator).
• Transactions should span the minimum time possible as transactions lock database rows.
• Use clustering for scalability.
• Use the HttpSession object rather than a Stateful session bean to maintain client state.
• Use Lazy loading to avoid unnecessary pre-loading of child data.
• Create read-only entity beans for read only operations.
• Use a dirty flag where supported by the EJB server to avoid writing unchanged EJBs to the database.
• Commit the data after the transaction completes rather than after each method call (where supported by EJB server).
• Do bulk updates to reduce database calls.
• Use JDBC directly rather than using entity beans when dealing with large amounts of data such as searching a large database.
• Combine business logic with the entity bean that holds the data needed for that logic to process.

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

• Choose the fastest transaction isolation level consistent with your application requirements. Levels from fastest to slowest are: TRANSACTION_NONE, TRANSACTION_READ_UNCOMMITED, TRANSACTION_READ_COMMITED, TRANSACTION_REPEATABLE_READ, TRANSACTION_SERIALIZABLE.
• Write SQL queries that minimize the data returned.
• Use the Page-by-Page Iterator pattern to repeatedly pass small amounts of data rather than huge chunks.

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

• Flush the data in sections so that the user can see partial pages more quickly.
• Session mechanisms from fastest to slowest are: HttpSession, Hidden fields, Cookies, URL rewriting, the persistency mechanism.

http://www.onjava.com/pub/a/onjava/2002/07/17/web.html
High load web servlets (Page last updated July 2002, Added 2002-07-24, Author Pier Fumagalli, Publisher OnJava). Tips:

• Hand off requests for static resources directly to the web server by specifying the URL, not by redirecting from the servlet.
• Use separate webservers to deliver static and dynamic content.
• Load balance the Java application using multiple JVMs.

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

• Flush the data in sections so that the user can see partial pages more quickly.
• Custom tags incur a performance overhead. Use as few as possible.
• Session mechanisms from fastest to slowest are: session, Hidden fields, Cookies, URL rewriting, the persistency mechanism.

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

• Use separate transactional sessions and non-transactional sessions for transactional and non-transactional messages.
• Receive messages asynchronously with a MessageListener implementation.

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

• The ServiceLocator/EJBHomeFactory Pattern reduces the expensive JNDI lookup process by caching EJBHome objects.
• The SessionFacade Pattern reduces network calls by combining accesses to multiple Entity beans into one access to the facade object.
• The MessageFacade/ServiceActivator Pattern moves method calls into a separate object which can execute asynchronously.
• The ValueObject Pattern combines remote data into one serializable object, thus reducing the number of network transfers required to access multiple items of remote data.
• The ValueObjectFactory/ValueObjectAssembler Pattern combines remote data from multiple remote objects into one serializable object, thus reducing the number of network transfers required to access multiple items of remote data.
• The ValueListHandler Pattern: avoids using multiple Entity beans to access the database, using Data Access Objects which explicitly query the database; and returns the data to the client in batches (which can be terminated) rather than in one big chunk, according to the Page-by-Page Iterator pattern.
• The CompositeEntity Pattern reduces the number of actual entity beans by wrapping multiple java objects (which could otherwise be Entity beans) into one Entity bean.

http://softwaredev.earthweb.com/java/article/0,,12082_862481,00.html
Writing a seamless audio looper (Page last updated August 2001, Added 2001-08-20, Author Greg Travis, Publisher EarthWeb). Tips:

• Switching audio streams from one piece of sound to another requires some fiddly managing of the transition delay in order to avoid a gap in the audio output.
• To avoid the transition delay, you need to: flush the output buffer; find out how much data was dumped; add a fudge factor; and combine these values to determine from where to start playing the new audio stream.

http://www.javaworld.com/javaworld/jw-07-2002/jw-0703-service.html
The Verified Service Locator pattern (Page last updated July 2002, Added 2002-07-24, Author Paulo Caroli, Publication JavaWorld, Publisher JavaWorld). Tips:

• The Service Locator pattern improves performance by caching service objects that have a high-lookup cost.
• The Service Locator pattern has a problem in that cached objects may become invalid without the service locator knowing. The Verified Service Locator pattern periodically tests the validity of the caches objects to avoid providing invalid service objects to requestors.

http://developer.java.sun.com/developer/community/chat/JavaLive/2002/jl0515.html
Sun Community chat on Java BluePrints (Page last updated May 2002, Added 2002-07-24, Author Edward Ort, Publication Sun Developer, Publisher Sun). Tips:

• Make tightly coupled components local to each other. Put remote beans primarily as facades across subsystems.
• The page-by-page pattern is designed to handle cases where the result set is large, and the end-user is not interested in seeing all of the results. There is really no upper threshold for the size of result set in the pattern.

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:

• A hardware- or software-based HTTP load-balancer usually sits in front of the application servers within a cluster. The load balancer can decrypt HTTPS requests and distribute load.
• HTTP session replication is expensive for a J2EE application server. If you can live with forcing a user to log in again after a server failure, then an HTTP load-balancer probably provides all of the fail-over and load-balancing functionality you need.
• 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://billharlan.com/pub/papers/Improving_Swing_Performance.html
Swing performance tips (Page last updated 1999, Added 2001-05-21, Author Bill Harlan, Publisher Harlan). Tips:

• Action listeners are all executed in the one event-dispatching thread. Time-consuming listeners should execute their work in a separate thread and should avoid blocking the event-dispatching thread. (To reenter the event-dispatching thread calling SwingUtilities.invokeLater() or invokeAndWait()).

http://www.stqemagazine.com/featured.asp?id=10
Web application scalability. (Page last updated June 2000, Added 2001-05-21, Author Billie Shea, Publisher STQE Magazine). Tips:

• Avoid deploying an application server that will cause embarrassment, or that could weaken customer confidence and business reputation [because of bad response times or lack of calability].
• Validate the architecture: decide on the maximum scaling requirements and then performance test to validate the necessary performance is achievable. This testing should be done on the prototype, before the application is built.
• Factor in load-balancing software and/or hardware in order to efficiently route requests to the least busy resource.
• Consider the effects security will have on performance: adding a security layer to transactions will impact response times. Dedicate specific server(s) to handle secure transactions.
• When application transaction volumes reach 40% of maximum expected volumes, it is time to start executing plans to expand the system

http://www.theserverside.com/resources/articles/JSP-Performance/ProJsp.html
Performance chapter (chapter 20) from "Professional JSP 2nd Edition" (Page last updated August 2001, Added 2001-10-22, Author Simon Brown, Robert Burdick, Darko Cokor, Jayson Falkner, Ben Galbraith, RodJohnson, Larry Kim, Casey Kochmer, Thor Kristmundsson, Sing Li, Dan Malks, Mark Nelson, Grant Palmer, Bob Sullivan, Geoff Taylor, John Timney, Sameer Tyagi, Geert Van Damme, Steve Wilkinson, Publisher The Server Side). Tips:

• The user's view of the response time for a page view in his browser depends on download speed and on the complexity of the page. e.g. the number of graphics. A poorly-designed highly graphical dynamic website could be seen as 'slow' even if the web downloads are individually quite fast.
• No web application can handle an unlimited number of requests; the trick in optimization is to anticipate the likely user demand and ensure that the web site can gracefully scale up to the demand while maintaining acceptable levels of speed.
• There is little performance penalty to using an MVC architecture.
• Use resource pools for expensive resources (like database connections).
• Static pages are much faster than dynamic pages, where the web server handles static pages separately.

http://developer.java.sun.com/developer/Books/performance2/chap3.pdf
Chapter 3 of "High Performance Java Computing : Multi-Threaded and Networked Programming", "Race Conditions and Mutual Exclusion" (Page last updated January 2001, Added 2001-02-21, Authors George Thiruvathukal, Thomas Christopher, Publisher Sun). Tips:

• [The chapter describes implementations for lock objects (wait until unlocked), counting semaphore objects (wait until positive), barrier sempahore objects (wait until last thread is finished), future objects (wait until a variable is first set). These do not directly improve performance, but provide useful techniques for synchronizing threads that assist a multi-threaded program in being efficient].
• Use resource enumeration (acquire resources in a set order) to avoid deadlocks.

http://developer.java.sun.com/developer/Books/performance2/chap4.pdf
Chapter 4 of "High Performance Java Computing : Multi-Threaded and Networked Programming", "Monitors" (Page last updated January 2001, Added 2001-02-21, Authors George Thiruvathukal, Thomas Christopher, Publisher Sun). Tips:

• Java monitors are not necessarily the most efficient synchronization mechanism, especially if transferring the lock can lead to a race condition [chapter discusses a more complete Monitor class].
• [The chapter discusses various policies for synchronizing threads trying to read from or write to shared resources, which provide different scheduling policies: one thread at a time; readers-preferred (readers have priority); writers-preferred (writers have priority); alternating readers-writers (alternates between a single writer and a batch of readers); take-a-number (first-come, first-served)].

http://www.javaworld.com/javaworld/jw-02-2001/jw-0223-performance.html
Designing Java Performance: reducing object creation (Page last updated March 2001, Added 2001-03-21, Author Brian Goetz, Publisher JavaWorld). Tips:

• Watch out for method interfaces which force unnecessary or inefficient object creation.
• Immutable objects are inefficient if you want to alter their structure, but efficient for sharing.
• One way to avoid creating objects simply for information is to provide finer-grained methods which return information as primitives. This swaps object creation for increased method calls.
• A second technique to avoid creating objects is to provide methods which accept dummy information objects that have their state overwritten to pass the information.
• A third technique to avoid creating objects is to provide immutable classes with mutable subclasses, by having state defined as protected in the superclass, but with no public updators. The subclass provides public updators, hence making it mutable.
• Don't try to speed up the application if there is no performance problem.

http://www.onjava.com/pub/a/onjava/2002/01/09/dataexp1.html
Expiring cached data (Page last updated January 2001, Added 2002-01-25, Author William Grosso, Publisher OnJava). Tips:

• [Article discusses and implements a time-based expiration framework].

http://portals.devx.com/Nokia/Article/6218
J2ME game building (Page last updated April 2002, Added 2002-05-19, Author Dale Crowley, Publisher DevX). Tips:

• Smart graphics is important: you need to draw clear, concise images at extremely low resolutions and with very small palettes. Animated characters need dynamic, easily-read poses which avoid kicks looking like a dance steps, or punches looking like an arm waves.
• Use public variables in your classes, rather than using accessors. This is technically bad programming practice but it saves bytecode space.
• Try to reduce the number of classes used. Combine classes into one if they vary only slightly in behavior. Every class adds size overheads.

http://lists.xml.org/archives/xml-dev/200201/msg00477.html
Email summarizing best practices for Promoting Scalable Web Services (Page last updated January 2002, Added 2002-02-22, Author Roger L. Costello, Publisher Costello). Tips:

• Web services best practices are mainly the same as guidelines for developing other distributed systems.
• Stay away from using XML messaging to do fine-grained RPC, e.g. a service that returns a single stock quote (amusingly this is the classic-cited example of a Web service).
• Do use course-grained RPC, that is, use Web services that "do a lot of work, and return a lot of information".
• When the transport may be slow and/or unreliable, or the processing is complex and/or long-running, consider an asynchronous messaging model.
• Take the frequency of the messaging into account. Replicate data as necessary.
• For aggregation services, try to retrieve data during off-hours in large, course-grained transactions.

http://www.ociweb.com/jnb/jnbMar2002.html
Object Resource Pooling (Page last updated March 2002, Added 2002-03-25, Author Paul King, Publisher OCI). Tips:

• If the overhead associated with creating a sharable resource is expensive, that resource is a good candidate for pooling.
• Pooled objects create a resource in advance and store it away so it can be reused over-and-over.
• Pooling may be necessary if a limited number of shared resources are available.
• Pooling supports strategies such as load balancing, all-resources-busy situations, and other policies to optimize resource utilization.
• [Article discusses pooling characteristics].
• Load balancing is possible by varying how pooled objects are handed out.
• Pool size can be tuned using low-water and high-water marks.
• Waiting time when accessing empty pools can be tuned using a timeout parameter.
• Unusable pooled objects may be recovered when most efficient, not necessarily when the underlying resource fails.
• The Recycler pattern fixes only the broken parts of a failed object, to minimize the replacement cost.

http://www-106.ibm.com/developerworks/java/library/j-javaio/
Using NIO (Page last updated March 2002, Added 2002-03-25, Author Aruna Kalagnanam and Balu G., Publisher IBM). Tips:

• The Reactor design pattern demultiplexes events and dispatches them to registered object handlers. (The Observer pattern is similar, but handles only a single source of events where the Reactor pattern handles multiple event sources).

http://www.hpmiddleware.com/newsletters/webservicesnews/features/
J2EE best practices. (Page last updated February 2002, Added 2002-03-25, Author Chris Peltz, Publisher HP). Tips:

• Executing a search against the database calls one of the finder() methods. finder() methods must return a collection of remote interfaces, not ValueObjects. Consequently the client would need to make a separate remote call for each remote interface received, to acquire data. The SessionFacade pattern suggests using a session bean to encapsulate the query and return a collection of ValueObjects, thus making the request a single transfer each way.
• The Value Object Assembler pattern uses a Session EJB to aggregate all required data as various types of ValueObjects. This pattern is used to satisfy one or more queries a client might need to execute in order to display multiple data types.

http://www.onjava.com/pub/a/onjava/excerpt/wirelessjava_ch5/index3.html
MIDP GUI programming (Page last updated March 2002, Added 2002-03-25, Author Qusay Mahmoud, Publisher OnJava). Tips:

• Entering alphanumeric data through a handheld device can be tedious. If possible, provide a list of choices from which the user can select.

http://www-106.ibm.com/developerworks/webservices/library/ws-testsoap/
Scaling SOAP-based web services. (Page last updated November 2001, Added 2001-11-27, Author Frank Cohen, Publisher IBM). Tips:

• Use simple SOAP data types (String, Int, Float, NegativeInteger).
• Each new data type introduces a serializer to convert from the XML value into a Java value and back again, which may cause performance problems.
• SOAP messages move much more data than the average HTTP GET or POST call, adversely impacting network performance.

http://www7b.boulder.ibm.com/wsdd/library/techarticles/0106_brown/sessionfacades.html
Rules and Patterns for Session Facades (Page last updated June 2001, Added 2001-07-20, Author Kyle Brown, Publisher IBM). Tips:

• Use the Facade pattern, and specifically Value objects, to transfer all the subset of data needed from an entity bean in one transfer.

http://www.onjava.com/pub/a/onjava/2001/12/19/eejbs.html
EJBs are wonderful (Page last updated December 2001, Added 2001-12-26, Author Tyler Jewell, Publisher OnJava). Tips:

• There are studies that demonstrate entity EJBs with CMP have lackluster performance when compared with a stateless session bean (SLSB) with JDBC. [Author points out however that SLSB/JDBC combination is less robust, less configurable, and less maintainable].
• Configure separate deployments for each entity bean for different usage patterns (e.g. typical 85% read-only, 10% read-write, 5% batch update), and partition the presentation layer to use the appropriate corresponding deployment (e.g. read requests use the read-only deployment).

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:

• Design coarse-grained EJB remote interfaces to reduce the number of network calls required.
• Combine remote method calls into one call, and combine the data required for the calls into one transfer.
• Use session bean wrapper for returning multiple data rows from an entity bean, rather than returning one row at a time.
• Use session beans for database batch operations, entity beans typically operate only one row at a time.
• Use entity beans when only a few rows are required for the entity, and when rows need to be frequently updated.

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:

• Send groups of objects together rather than one object at a time.
• Pack data to reduce the number and amount of reads and writes, and the amount of data transferred.

http://www.sys-con.com/java/article.cfm?id=1160
Local entity beans (Page last updated October 2001, Added 2001-10-22, Author Alex Pestrikov, Publisher Java Developers Journal). Tips:

• Facade objects (wrappers) allow local entity beans to be called remotely. This pattern incurs very little overhead for remote calls, while at the same time optimizing local calls between local beans which can use local calls.

http://developer.java.sun.com/developer/Books/programming/performance/eperformance/eJavaCh01.pdf
Chapter 1 of "Enterprise Java Performance", "Performance in General". Includes the infamous sentences "It is likely that the code will not meet the performance requirements the very first time it runs. Even if it does, it may be worthwhile to look for some ways to improve it." NO NO NO! If the code meets the performance requirements, DON'T CHANGE IT. Next time guys, ask me to review your book before you publish. (Page last updated 2000, Added 2000-10-23, Authors Steven Halter & Steven Munroe, Publisher Sun). Tips:

• Define performance requirements explicitly. Redefine fuzzy requirements to be more explicit.
• Keep performance in mind during the design phase.
• Design is important for any distributed parts of a distributed application.
• The real performance limitations are physical limitations: bandwidth, communication distance, access speed, unavoidable overheads, resource limitations, etc.
• Schema mapping is complex. [Buy a product that does it for you.]

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].
• Persistency adds overheads that make persistent objects slower.
• 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.
• 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://www.awlonline.com/product/0,2627,0201616467,00.html
Peter Haggar's Practical Java Programming Language Guide. (Page last updated 2000, Added 2001-01-19, Author Peter Haggar, Publisher Addison-Wesley). Tips:

• Focus initially on design, data structures, and algorithms.

http://www.onjava.com/pub/a/onjava/synd/2001/08/15/embedded.html
Performance tuning embedded Java (Page last updated August 2001, Added 2001-08-20, Author Vincent Perrier, Publisher OnJava). Tips:

• All the following affect embedded Java performance: hardware processor selection; (real-time) operating system selection; supported Java APIs; application reliability and scalability; graphics support; and the ability to put the application code into ROM.

http://www.sys-con.com/java/article.cfm?id=712
J2EE challenges (Page last updated June 2001, Added 2001-07-20, Author Chris Kampmeier, Publisher Java Developers Journal). Tips:

• To ensure good performance use experienced J2EE builders and use proven design patterns.
• Consider the impact of session size on performance.
• Performance requirements include: the required response times for end users; the perceived steady state and peak user loads; the average and peak amount of data transferred per Web request; the expected growth in user load over the next 12 months.
• Note that peak user loads are the number of concurrent sessions being managed by the application server, not the number of possible users using the system.
• Additional capacity should be designed into the system.

http://www.sys-con.com/java/article.cfm?id=673
J2EE Application servers (Page last updated April 2001, Added 2001-04-20, Authors Christopher G. Chelliah and Sudhakar Ramakrishnan, Publisher Java Developers Journal). Tips:

• A scalable server application probably needs to be balanced across multiple JVMs (possibly pseudo-JVMs, i.e. multiple logical JVMs running in the same process).
• Performance of an application server hinges on caching, load balancing, fault tolerance, and clustering.
• Load balancing mechanisms include: round-robin DNS (alternating different IP-addresses assigned to a server name); and re-routing mechanisms to distribute requests across multiple servers. By maintaining multiple re-routing servers and a client connection mechanism that automatically checks for an available re-routing server, fault tolerance is added.
• Using one thread per user can become a bottleneck if there are a large number of concurrent users.
• Distributed components should consider the proximity of components to their data (i.e., avoid network round-trips) and how to distribute any resource bottlenecks (i.e., CPU, memory, I/O) across the different nodes.

http://www.javaworld.com/javaworld/jw-07-2001/jw-0713-optimism.html
The Optimistic Locking pattern (Page last updated July 2001, Added 2001-07-20, Author Yasmin Akbar-Husain and Eoin Lane, Publisher JavaWorld). Tips:

• Pessimistic locking, where database data is locked when read, can lead to high lock contention.
• Optimistic locking only checks data integrity at update time, so has no lock contention [but can have high rollback costs]. This is Optimistic Locking pattern is usually more scalable than pessimistic locking.
• Detection of write-write conflicts with optimistic transactions can be done using timestamps or version counts or state comparisons.

http://www.microjava.com/articles/techtalk/recylcle2
Object recycling part 2 (Page last updated February 2002, Added 2002-02-22, Author Angus Muir and Roman Bialach, Publisher Micro Java). Tips:

• The efficiency of pooling objects compared to creating and disposing of objects is highly dependent on the size and complexity of the objects.
• Object pools have deterministic access and reclamation costs for both CPU and memory, whereas object creation and garbage collection can be less deterministic.

http://www.javaworld.com/javaworld/jw-03-1996/jw-03-animation.html
Animation in java applets article. Old article, but basically sound (the basics haven't changed). (Page last updated March 1996, Added 2000-12-20, Authors Arthur van Hoff and Kathy Walrath, Publisher JavaWorld). Tips:

• Use a separate thread to draw the animation. Do not use the paint() method.
• Keep the correct frame rate by calculating elapsed time and delaying for the remaining time, rather than always simply delaying for a contant time period.

http://java.sun.com/docs/books/tutorial/uiswing/painting/animation.html
Another tutorial from Sun. This ones on animation (Page last updated ?, Added 2000-12-20, Author ?, Publisher Sun). Tips:

• Normal frame rates for animation: 8 frames per second (fps) for poor quality animation; 12 fps for standard animation; 24 fps for short bursts of smooth, realistic motion.
• Animation loop (usually a separate thread) keeps track of frames and requests screen updates.

http://www.cs.tcd.ie/courses/baict/bacs/sf/Animation/
Basic animation tutorial (Page last updated ?, Added 2000-12-20, Author Dave ?, Publisher ?). Tips:

• Use a separate thread to manage the calculations and drawing.

http://www.sys-con.com/java/article.cfm?id=713
Moving from JSP to EJB (Page last updated June 2001, Added 2001-06-18, Author Patrick Sean Neville, Publisher Java Developers Journal). Tips:

• Entity EJBs should contain aggregate get/set methods that return chunks of data rather than fine-grained get/set methods for individual attributes, to reduce unnecessary database, transactional, and network communication overheads.
• Avoid stateful session beans as they are resource-heavy, since one instance is maintained for each client.
• Under heavy loads, entity beans should do more than merely represent a table in a database. If you are merely retrieving and updating data values, consider using JDBC within session beans instead.
• If you have one large database host but only a small Web and middleware host, consider moving much of your logic into stored procedures and calling them via JDBC in session beans.
• Consider using a single stateless session bean to provide access to other EJBs (this is a façade pattern). This optimizes multiple EJB references and calls by keeping them in-process.

http://www.devx.com/judgingjava/articles/maso/default.asp
Judging various aspects of Java, including performance (Page last updated May 2001, Added 2001-06-18, Author Brian Maso, Publisher DevX). Tips:

• J2EE defines component models with high scalability potential. Maximizing scalability requires sticking to stateless session beans and handling all database interactions programmatically (through pooled JDBC connections).
• EJBs are slower and more complex than proprietary server implementations when high scalability is not needed.

http://developer.java.sun.com/developer/technicalArticles/InnerWorkings/JDCPerformTips/index.html
Various performance tips from a JavaOne 1998 presentation. (Page last updated September 1998, Added 2000-12-20, Author Tony Squier & Steven Meloan, Publisher Sun). Tips:

• Minimize the number of times that an applet has to request data from the server.
• Use Thread pools where these improve performance.

http://www.onjava.com/pub/a/onjava/2001/09/26/load.html
Load Balancing Web Applications (Page last updated September 2001, Added 2001-10-22, Author Vivek Veek, Publisher OnJava). Tips:

• DNS round-robin sends each subsequent DNS lookup request to the next entry for that server name. This provides a simple machine-level load-balancing mechanism, but is only appropriate for session independent or shared-session servers.
• DNS round-robin has no server load measuring mechanisms, so requests can still go to overloaded servers, i.e. the load balancing can be very unbalanced.
• Hardware load-balancers solve many of the problems of DNS round-robin, but introduce a single point of failure.
• A web server proxy can also provide load-balancing by redirecting requests to multiple backend webservers.

http://www.javaworld.com/javaworld/jw-02-2001/jw-0202-cachedrow.html
Article on using CachedRowSet, a ResultSet that doesn't need continuous connection to the database (Page last updated February 2001, Added 2001-02-21, Author Taylor G. Cowan, Publisher JavaWorld). Tips:

• CachedRowSet is probably not appropriate for managing large datasets.

http://www-106.ibm.com/developerworks/java/library/j-jtctips/j-jtc0319a.html
Finalizers (Page last updated March 2002, Added 2002-04-26, Author Phil Vickers, Publisher IBM). Tips:

• Adding finalizers to your code makes GC much more expensive and unpredictable.
• Finalizers are not executed at a predictable time.

http://www.sys-con.com/java/article.cfm?id=1301
JMS & JCACHE (Page last updated February 2002, Added 2002-02-22, Author Steve Ross-Talbot, Publisher Java Developers Journal). Tips:

• Asynchronous messaged communications allows subsystems to decouple and work more efficiently in parallel, more closely reflecting actual workflows.
• Event-driven systems tend to be more scalable.

http://www.onjava.com/pub/a/onjava/2001/03/01/pseudo_sessions.html
Pseudo Sessions for JSP, Servlets and HTTP (Page last updated March 2001, Added 2001-03-21, Author Budi Kurniawan, Publisher OnJava). Tips:

• Use pseudo sessions rather than HttpSessions to improve web server scalability.
• Pseudo sessions reside on file instead of in memory, thus both decreasing memory and allowing sessions to be distributed across multiple servers.
• Pseudo sessions do not use cookies, instead they alter URLs to encode the session, an