JAVA Related Performance Tuning Tips - Part 1

Improving J2EE performance improves Tips:

• Set performance goals before development starts.
• 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.
• Cache data to minimize lookup time, though this can reduce scalability if locks are required to access the cache.
• If there are more accesses than updates to a cache, share the access lock amongst all the accessors, though be aware that this reduces the window for updators to lock the cache.
• For optimum performance, zero shared memory provides a cache per user.
• Be methodical to ensure that changes for performance do actually improve performance.
• Eliminate memory leaks before tuning execution speed.
• Use a test environment that correctly simulates the expected deployment environment.
• Simulate the expected client activity, and compare the performance against your expected goals.
• Consider which metrics to measure, such as: Max response time under heavy load; CPU utilization under heavy load; How the application scales as additional users are added.
• Profile the application to find the bottlenecks. Correct bottlenecks by making one change at a time and testing for improvement.
• Generate stack traces to look for bottlenecks which are multi-thread conflicts (waiting for locks).
• Improving the performance of a method that is called 1000 times and takes a tenth of a second on average each call, is better than improving the performance of a method that is only called 10 times but takes 1 second each call.
• Don?t cache data unless you know how and when to invalidate the cached entries.

J2EE Performance tuning Tips:

• Call HttpSession.invalidate() to clean up a session when you no longer need to use it.
• For Web pages that don't require session tracking, save resources by turning off automatic session creation using: <%@ page session="false"%>
• Implement the HttpSessionBindingListener for all beans that are scoped as session interface and explicitly release resources implementing the method valueUnbound().
• Timeout sessions more quickly by setting the timeout or using session.setMaxInactiveInterval().
• Keep-Alive may be extra overhead for dynamic sites.
• Use the include directive <%@ include file="copyleft.html" %> where possible, as this is a compile-time directive (include action <jsp:include page="copyleft.jsp" /> is a runtime directive).
• Use cache tagging where possible.
• Always access entity beans from session beans.
• If only using an entity bean for data access, use JDBC directly instead.
• Use read-only in the deployment descriptor.
• Cache access to EJB homes.
• Use local entity beans when beans are co-located in the same JVM.
• Proprietary stubs can be used for caching and batching data.
• Use a dedicated remote object to generate unique primary keys.

EJB performance 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.
• Control serialization by modifying unnecessary data variables with 'transient' key word to avoid unnecessary data transfer over network.
• Cache EJBHome references to avoid JNDI lookup overhead (pattern called ServiceLocator).
• Declare non-transactional methods of session beans with 'NotSupported' or 'Never' transaction attributes (in the ejb-jar.xml deployment descriptor file).
• Transactions should span the minimum time possible as transactions lock database rows.
• Set the transaction time-out (in the ejb-jar.xml deployment descriptor file).
• Use clustering for scalability.
• Tune the EJB Server thread count.
• Use the HttpSession object rather than a Stateful session bean to maintain client state.
• Use the ECperf benchmark to help differentiate EJB server performances.
• Tune the Stateless session beans pool size to minimize the creation and destruction of beans.
• Use the setSessionContext() or ejbCreate() method to cache bean specific resources. Release acquired resources in the ejbRemove() method.
• Tune the Stateful session beans cache size to and time-out minimize activations and passivations.
• Allow stateful session beans to be removed from the container cache by explicitly using the remove() method in the client.
• Tune the entity beans pool size to minimize the creation and destruction of beans.
• Tune the entity beans cache size to minimize the activation and passivation of beans (and associated database calls).
• Use the setEntityContext() method to cache bean specific resources and release them from the unSetEntityContext() method.
• Use Lazy loading to avoid unnecessary pre-loading of child data.
• Choose the lowest cost transaction isolation level that avoids corrupting the data. Transaction levels in increasing cost are: TRANSACTION_READ_UNCOMMITED, TRANSACTION_READ_COMMITED, TRANSACTION_REPEATABLE_READ, TRANSACTION_SERIALIZABLE.
• Use the lowest cost locking available from the database that is consistent with any transaction.
• 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 CMP rather than BMP to utilize built-in performance optimization facilities of CMP.
• Use ejbHome() methods for global operations (from EJB2.0).
• Tune the connection pool size to minimize the creation and destruction of database connections.
• 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.
• Tune the Message driven beans pool size to optimize the concurrent processing of messages.
• Use the setMesssageDrivenContext() or ejbCreate() method to cache bean specific resources, and release those resources from the ejbRemove() method.