10 tips for building high-performance J2EE applications

To build a high-performance J2EE application, you must understand common implementation skills. The following describes the 10 most commonly used effective methods to help architects quickly become experts in this field.

Java performance basics-memory management

The performance of any Java application, standalone or J2EE can be attributed to how your application manages memory. Java memory management includes two important tasks: Memory Allocation and memory recovery. In memory allocation, the goal is to reduce the objects to be created. Memory recycling is a common cause of performance degradation. That is to say, the more objects in the memory, the more difficult it is to recycle garbage. Therefore, the more conservative we are to create objects, the better.

Two common memory-related problems in J2EE applications are: Free objects (also known as Memory leakage) and object loop (that is, a large number of frequent creation and deletion-embodied in Java as removing reference-object ).

Make sure that all reachable objects are actually active, that is, these objects exist not only in the memory, but also in the executed code. When the object is no longer used in the application, but we forget to delete the reference to the object, the free object will appear.

We know that garbage collection will take up CPU time. A large number of short-term object creation increases the garbage collection frequency, which may cause performance degradation.

Do not implement business logic in Servlet

When building a J2EE application, architecture engineers usually use the basic part of J2EE, servlet.

If the architect does not use session beans, entity beans, or message beans, there are few ways to improve performance. You can only add CPU or more physical servers. EJB uses caching and resource pools to improve performance and scalability.

Use the local interface to access EJB as much as possible

In early J2EE (following ejb1.x specifications) applications, access to EJB is achieved through remote interfaces through RMI. With the emergence of ejb2.0, you can access ejbs through local interfaces instead of using RMI. There are fewer remote methods in the same JVM. However, there are still some applications implemented using ejb1.x and some new EJB users who do not know how to use the local interface. To illustrate this, let's make a comparison:
1. The client application calls the local stub
2. The stub Assembly Parameters
3. The stub is uploaded to skeleton.
4. This skeleton decomposition Parameter
5. the skeleton calls the EJB object.
6. The EJB object executes the container service.
7. The EJB object calls the enterprise Bean instance.
8. Enterprise Bea performs operations
9. Execute the Assembly/decomposition steps and return

Compared with remote interface processing, the local interface's EJB method is:
1. The client calls a local object
2. Run Container service on local objects
3. Local objects call enterprise Bean instances
4. perform operations on enterprise Bean instances
5. No other return steps !!

If you do not need to access a special EJB from a remote client, you should use the local method.

Encapsulate access to the entity EJB in the service implementing Session Bean

Accessing the object EJB from servlet is not only inefficient but also difficult to maintain. In Session Facade mode, you can encapsulate the access to the entity EJB in session EJB. In this session EJB, you can use a local interface to access the entity EJB to avoid excessive remote calls.

This technology has additional performance and scalability benefits because sessions and entity ejbs can be improved using the cache and resource pool technologies. In addition, due to load requirements, sessions and entity ejbs can be extended and deployed on other hardware devices, which is much easier than extending servlet layer replication to other hardware devices.

Access remote ejbs with coarse granularity as much as possible

When you access remote ejbs, calling the set/get method will generate too many network requests and overload remote interface processing. To avoid this situation, you can concentrate data attributes in an object so that all data can be transmitted through a call to remote EJB. This technology is the data transfer object mode.

Optimize SQL

The architecture design engineers and developers of J2EE are generally not SQL experts or experienced database administrators. First, make sure that SQL uses the index support provided by the database. In some cases, separating the indexes and data of the database improves the performance. However, adding additional indexes can improve select performance but also reduce insert performance. For some databases, sorting between associated tables seriously affects performance. Consult with the database administrator.

Avoid excessive SQL Execution in the Entity EJB

Sometimes, multiple SQL statements are executed when data is accessed through the entity EJB. According to the J2EE specification, the first step is to call the find (discovery) method of the Entity Bean. The second step is to call the ejbload () method when the business method of the entity EJB is called for the first time () obtain information from the database.

Many CMP (container management persistence) caches the object data when calling the discovery method, so they no longer access the database when calling ejbload. You should avoid using BMP (persistence of bean management) or implementing your own cache algorithm to avoid secondary access to the database.

Access read-only data in Fast Lane reader mode

J2EE applications often need to read-only access a large amount of data that remains unchanged for a long time, rather than accessing a single entity, such as browsing online product directories. In this read-only case, using an entity EJB to access data can cause serious overload and cause trouble in implementation. Entity ejbs are suitable for coarse-grained access to a single entity, and the read-only data access rate to a large number of lists is not high. Whether using CMP or BMP, you must write code to operate on multiple entity ejbs and their associations. This will lead to access to multiple databases with a large amount of unnecessary transaction overhead.

Use Java messaging Servce (Message Service)

The J2EE specification provides a built-in asynchronous processing service in JMS. When it comes to system requirements, you should know under what circumstances should JMS be used for asynchronous processing design. Once it is determined that some asynchronous processing is required, the fewer synchronization tasks, the better, and the database-intensive operations will be completed in later asynchronous processing.

Cache JNDI Lookup

Many operations consume a large amount of resources during the JNDI search. The JNDI resources should be cached to avoid network calls and some handling overload. Available cache JNDI searches include:
EJB home Interfaces
Data sources
JMS connection factories
MS destinations/topics

Some JNDI packages implement the cache function. However, when calling the narrow method for the main EJB interface, this function has limited function.

The cache search design should use the shared intialcontext instance, although it is very troublesome to build it. This is because you need to access a variety of data sources, including the Application resource file JNDI. properties, system attribute parameters, and the parameters passed to the constructor.