Best Practice 9 - Minimize use of System.out.println
Because it seems harmless, this commonly used application development legacy is overlooked for the performance problem it really is. Because System.out.println statements and similar constructs synchronize processing for the duration of disk I/O, they can significantly slow throughput.
Best Practice 10 - Avoid String concatenation “+=”
String concatenation is the textbook bad practice that illustrates the adverse performance impact of creating large numbers of temporary Java objects. Because Strings are immutable objects, String concatenation results in temporary object creation that increases Java garbage collection and consequently CPU utilization as well.
The textbook solution is to use java.lang.StringBuffer instead of string concatenation.
Best Practice 11 - Access entity beans from session beans
Avoid accessing EJB entity beans from client or servlet code. Instead wrap and access EJB entity beans in EJB session beans. This best practice satisfies two performance concerns:
Reducing the number of remote method calls. When the client application accesses the entity bean directly, each getter method is a remote call. A wrapping session bean can access the entity bean locally, and collect the data in a structure, which it returns by value.
Providing an outer transaction context for the EJB entity bean: An entity bean synchronizes its state with its underlying data store at the completion of each transaction. When the client application accesses the entity bean directly, each getter method becomes a complete transaction. A store and a load follow each method. When the session bean wraps the entity bean to provide an outer transaction context, the entity bean synchronizes its state when outer session bean reaches a transaction boundary.
Best Practice 12 - Reuse EJB homes
EJB homes are obtained from WebSphere Application Server through a JNDI naming lookup. This is an expensive operation that can be minimized by caching and reusing EJB Home objects.
Best Practice 13 - Use “Read-Only” methods where appropriate
When setting the deployment descriptor for an EJB Entity Bean, you can mark “getter” methods as “Read-Only.” If a transaction unit of work includes no methods other than ”Read-Only” designated methods, then the Entity Bean state synchronization will not invoke store.
Best Practice 14 - Reduce the transaction isolation level where Appropriate
By default, most developers deploy EJBs with the transaction isolation level set to TRANSACTION_SERIALIZABLE.
It is also the most restrictive and protected transaction isolation level incurring the most overhead.
Some workloads do not require the isolation level and protection afforded by TRANSACTION_SERIALIZABLE. A given application might never update the underlying data or be run with other concurrent updaters. In that case, the application would not have to be concerned with dirty, non-repeatable or phantom reads. TRANSACTION_READ_UNCOMMITTED would probably be sufficient.
Best Practice 15 - EJBs and Servlets - same JVM - “No local copies”
Because EJBs are inherently location independent, they use a remote programming model. Method parameters and return values are serialized over RMI-IIOP and returned by value. This is the intrinsic RMI “Call By Value” model.
WebSphere provides the “No Local Copies” performance optimization for running EJBs and clients (typically servlets) in the same application server JVM. The “No Local Copies” option uses “Call by Reference” and does not create local proxies for called objects when both the client and the remote object are in the same process. Depending on your workload, this can result in a significant overhead savings.
Best Practice 16 - Remove stateful session beans when finished
Instances of stateful session beans have affinity to specific clients. They will remain in the container until they are explicitly removed by the client, or removed by the container when they timeout. Meanwhile, the container might need to passivate inactive stateful session beans to disk. This requires overhead for the container and constitutes a performance hit to the application. If the passivated session bean is subsequently required by the application, the container activates it by restoring it from disk.
Best Practice 17 - Don’t use Beans.instantiate() to create new bean instances
The method, java.beans.Beans.instantiate(), will create a new bean instance either by retrieving a serialized version of the bean from disk or creating a new bean if the serialized form does not exist. The problem, from a performance perspective, is that each time java.beans.Beans.instantiate is called the file system is checked for a serialized version of the bean. As usual, such disk activity in the critical path of your web request can be costly. To avoid this overhead, simply use “new” to create the instance.
Because it seems harmless, this commonly used application development legacy is overlooked for the performance problem it really is. Because System.out.println statements and similar constructs synchronize processing for the duration of disk I/O, they can significantly slow throughput.
Best Practice 10 - Avoid String concatenation “+=”
String concatenation is the textbook bad practice that illustrates the adverse performance impact of creating large numbers of temporary Java objects. Because Strings are immutable objects, String concatenation results in temporary object creation that increases Java garbage collection and consequently CPU utilization as well.
The textbook solution is to use java.lang.StringBuffer instead of string concatenation.
Best Practice 11 - Access entity beans from session beans
Avoid accessing EJB entity beans from client or servlet code. Instead wrap and access EJB entity beans in EJB session beans. This best practice satisfies two performance concerns:
Reducing the number of remote method calls. When the client application accesses the entity bean directly, each getter method is a remote call. A wrapping session bean can access the entity bean locally, and collect the data in a structure, which it returns by value.
Providing an outer transaction context for the EJB entity bean: An entity bean synchronizes its state with its underlying data store at the completion of each transaction. When the client application accesses the entity bean directly, each getter method becomes a complete transaction. A store and a load follow each method. When the session bean wraps the entity bean to provide an outer transaction context, the entity bean synchronizes its state when outer session bean reaches a transaction boundary.
Best Practice 12 - Reuse EJB homes
EJB homes are obtained from WebSphere Application Server through a JNDI naming lookup. This is an expensive operation that can be minimized by caching and reusing EJB Home objects.
Best Practice 13 - Use “Read-Only” methods where appropriate
When setting the deployment descriptor for an EJB Entity Bean, you can mark “getter” methods as “Read-Only.” If a transaction unit of work includes no methods other than ”Read-Only” designated methods, then the Entity Bean state synchronization will not invoke store.
Best Practice 14 - Reduce the transaction isolation level where Appropriate
By default, most developers deploy EJBs with the transaction isolation level set to TRANSACTION_SERIALIZABLE.
It is also the most restrictive and protected transaction isolation level incurring the most overhead.
Some workloads do not require the isolation level and protection afforded by TRANSACTION_SERIALIZABLE. A given application might never update the underlying data or be run with other concurrent updaters. In that case, the application would not have to be concerned with dirty, non-repeatable or phantom reads. TRANSACTION_READ_UNCOMMITTED would probably be sufficient.
Best Practice 15 - EJBs and Servlets - same JVM - “No local copies”
Because EJBs are inherently location independent, they use a remote programming model. Method parameters and return values are serialized over RMI-IIOP and returned by value. This is the intrinsic RMI “Call By Value” model.
WebSphere provides the “No Local Copies” performance optimization for running EJBs and clients (typically servlets) in the same application server JVM. The “No Local Copies” option uses “Call by Reference” and does not create local proxies for called objects when both the client and the remote object are in the same process. Depending on your workload, this can result in a significant overhead savings.
Best Practice 16 - Remove stateful session beans when finished
Instances of stateful session beans have affinity to specific clients. They will remain in the container until they are explicitly removed by the client, or removed by the container when they timeout. Meanwhile, the container might need to passivate inactive stateful session beans to disk. This requires overhead for the container and constitutes a performance hit to the application. If the passivated session bean is subsequently required by the application, the container activates it by restoring it from disk.
Best Practice 17 - Don’t use Beans.instantiate() to create new bean instances
The method, java.beans.Beans.instantiate(), will create a new bean instance either by retrieving a serialized version of the bean from disk or creating a new bean if the serialized form does not exist. The problem, from a performance perspective, is that each time java.beans.Beans.instantiate is called the file system is checked for a serialized version of the bean. As usual, such disk activity in the critical path of your web request can be costly. To avoid this overhead, simply use “new” to create the instance.
