Shulou(Shulou.com)06/02 Report--

This article will explain in detail the common methods to solve the performance problems of J2EE application. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

In the application performance of J2EE system, the following more basic symptoms are often reflected:

Usage of application server resources

Usage of JVM heap

Usage of system resources

Usage of database resources

Network activity

These phenomena indicate that J2EE applications rely on a lot of external resources and are running in a hierarchical execution mode environment:

Because the Java virtual machine and application server conceal the characteristics of the operating system and hardware, architecture engineers should have a deeper understanding of the whole operating environment when designing software systems.

Next, architecture engineers can continue to look for reasons that are not obvious, such as the cumulative impact of algorithms and unnecessary overhead.

There are now many configuration projects for each J2EE application server on the market. Here is a brief introduction to some common performance optimization configuration projects.

Many application servers have some operating system configuration items or non-standard features related to the J2EE specification, which can improve system performance. It should take time to understand these performance configurations.

Java virtual machine heap and garbage collection settings

Any J2EE system application performance tuning basis involves heap size and garbage collection settings. Here we mainly discuss Sun HotSpor JVM.

The heap can be divided into three generations, young (new), old and lasting. The basic memory configuration of Hotspot JVM includes the maximum heap size, the initial heap size, and the younger generation heap size. You can refer to the following guidelines when configuring the maximum heap size:

The maximum heap size should be smaller than physical memory to avoid virtual page scheduling.

Need to subtract the memory used by other processes

Optimize during load testing

Be careful not to set the maximum heap size too large. The larger the heap, the more objects are saved in memory. The more objects in memory, the longer the recycling process.

General strategies for configuring pilot heap size include:

Set the initial size to the maximum heap size

Set the initial size to the maximum heap size of 1 _ swap 4 to 1 _ swap 2

For the younger generation heap size, Sun recommends that the heap size be set to a maximum heap size of 1max 3.

You can also choose different garbage collection algorithms. The first is incremental garbage collection. The algorithm means to reduce the recovery pause time of a single object, which results in a decline in the overall recovery performance. The algorithm groups objects that refer to each other and then attempts to recycle them by group. The smaller the part that you try to recycle, the less time it takes to recycle.

Version 1.4.1 of HotSpot JVM adds two garbage collection algorithms: parallel algorithm and concurrent algorithm.

Parallel algorithms are implemented in the younger generation heap. On multiprocessor machines, this recycling algorithm uses multithreading to improve performance. Although this algorithm pauses all application threads, the recycling time is very fast due to the use of multiple CPU. In the younger generation heap, the algorithm significantly reduces the pause caused by recycling.

The concurrency algorithm is implemented in the older generation heap. Maximize concurrency in the application. The recycling process is divided into four stages, covering the marking and clearing operations of recyclable objects. The first two processes pause the application thread, and the last two phases can be executed concurrently with the application. The "maximum concurrency" feature of the concurrent garbage collection algorithm enables JVM to take advantage of larger heaps and multiple CPU. Therefore, attention should be paid to the latency and throughput problems caused by the use of default garbage collection algorithms such as mark-compact (marking-compression) and stop-the-world (pausing all processing).

Processing thread

J2EE application server is a multithreaded application. The thread of the application server is a pool of resources that are shared with tasks such as processing requests and the internal functions of the application server.

Many application servers allow you to configure thread pools of different sizes for specific tasks or applications. You usually need to increase the size of these thread pools to meet the needs of the application load.

Architecture engineers should avoid setting the thread pool size too large because it increases the number of context exchanges, which reduces application performance. Thread pools should usually be large enough to take advantage of the CPU on the machine without overloading the CPU.

EJB configuration Project

In application servers, many different types of EJB are implemented in the form of resource pools.

Architecture engineers should avoid setting these pool sizes too large, which can lead to unnecessary consumption of JVM and operating system memory. In addition, setting the initial number of Bean too high will make the startup time of the application server unacceptably long.

In the application server, many different types of EJB are cached. Cache size and timeout settings often also have a significant impact on application performance.

Architecture engineers should avoid setting the buffer size too large, which also consumes large amounts of JVM and operating system memory unnecessarily. In addition, you should avoid setting excessively long timeouts-- such as being cached when EJB is not used-- which can also lead to unnecessary memory consumption.

Database configuration project

J2EE specification requires that application server vendors must provide database connection resource pool function. Increasing the size of the database connection pool usually improves performance. Architecture engineers should consider that different types of SQL operations (such as transactional and batch) should use different connection pooling. If a message Bean performs a batch operation, you should create another connection pool for this instead of using the same connection pool as the transactional operation.

Many J2EE application servers provide the caching capabilities of Prepared Statement. Creating a Prepared Statement takes a lot of resources. In transactional J2EE applications, many of the same SQL statements are usually executed, but with different parameters. Therefore, in the application, we should play the role of database configuration project and use Prepared Statement as much as possible.

On how to solve the common methods of J2EE system application performance problems is shared here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.