Top 10 problems affecting Java EE Performance

The original author of this article is a senior System Architect with more than 10 years of experience. He specializes in Java EE, middleware, and JVM technologies. He also has profound insights on performance optimization and improvement. Next he will share with you 10 common problems that affect Java EE performance.

1. Lack of proper capacity planning

Capacity planning is a comprehensive and evolving process standard that predicts current and future IT environment capacity requirements. Reasonable capacity planning not only ensures and tracks the current IT production capacity and stability, but also ensures that new projects are deployed to the existing production environment with minimum risks. Hardware, middleware, JVM, and adjustment should be prepared before project deployment.

2. Insufficient Java EE middleware environment specifications

"No rules, not a square ". The second common reason is that the Java EE middleware or infrastructure is not standard. At the beginning of the project, there were no reasonable specifications on the new platform, resulting in poor system stability. This will increase customer costs, so it is necessary to take time to develop reasonable Java EE middleware environment specifications. This work should be combined with the initial capacity planning iteration.

3. Excessive garbage collection on java virtual machines

Are you familiar with the error message "Java. Lang. outofmemoryerror? Exceptions thrown due to excessive JVM memory space consumption (Java heap, local heap, etc.

Garbage collection is not necessarily represented as an OOM condition, excessive garbage collection can be understood as the long JVM pause time and performance degradation caused by minor or excessive collection of data by jvm gc threads in a short time. There may be the following reasons:

1. Compared with the JVM load and application memory usage, the Java heap may be too small.
2. The jvm gc policy usage is unreasonable.
3. The static or dynamic memory usage of the application is too large and is not suitable for 32-bit JVM.
4. Over time, the JVM oldgen exposes more and more seriously, but GC does not discover it several hours or days later.
5. JVM permgen space (only hotspot VM) or local heap leakage over time is a very common problem; OOM errors are often observed after a period of time, the dynamic transfer of applications.
6. The younggen and oldgen ratios do not match your application.
7. The Java heap is too large on a 32-bit Vm, causing the local heap overflow, the specific manifestation is that OOM tries to link a new Java EE application, create a new Java thread, or calculate the local memory allocation task.

Suggestion:

1. Observe and gain an in-depth understanding of JVM garbage collection. Start GC and provide all the data based on reasonable health assessment.
2. Remember, GC problems are not found during development or functional testing. They need to be found in a multi-user high-load testing environment.

4. Too many or too few integration with external systems

The fourth cause of poor Java EE performance is the high distributed system. A typical case is the telecom IT environment. In this environment, a middleware field (for example, the Service Bus) Rarely does all the work, but simply delegates some businesses to other parts, such as product quality, customer Data and order management are applied to other Java EE middleware platforms or legacy systems, such as mainframes supporting various load types and communication protocols.

Such an external system call means that the client's Java EE application triggers the creation or reuse of socket links to read and write data from the external system. You can configure synchronous or asynchronous calls Based on the implementation and implementation of business processes. It should be noted that the response time will change according to the stability of the external system, so it is very important to protect Java EE applications and middleware through appropriate timeout.

The following three situations are frequently related to problems and performance degradation:

1. Too many external systems are synchronized and called one after another.
2. The connection timeout between the Java EE client application and the external system causes data loss or the value is too high, causing the client thread to get stuck, resulting in the pull effect.
3. Timeout, but the program is still running normally, but the middleware does not handle this strange path.

Finally, we recommend that you perform more negative tests, which means that you need to create conditions for these problems to test how the application and middleware handle external system errors.

5. Lack of proper database SQL optimization and capacity planning

Everyone may be surprised at this: Database problems. Most Java EE Enterprise systems rely on relational databases to process complex business processes. A solid and solid database environment ensures the growth of the IT environment to support growing businesses.

In practice, database-related performance problems are very common. Most database transactions are processed by JDBC data sources (including relational persistence APIs, such as Hibernate ). Performance problems are initially manifested as thread blocking.

The following are some of the database problems I have encountered during my 10 years of work (Taking ORACLE database as an example ):

1. Isolated, long-running SQL statements. The main features are thread blocking, SQL not optimized, missing indexes, unoptimal execution plans, and returning a large number of datasets.
2. Table or row-level data is locked. When committing a two-phase transaction model (for example, the notorious Oracle suspicious transaction ). The Java EE container may leave some unprocessed transactions waiting for the final commit or rollback. The data lock can trigger performance problems until the final lock is removed. For example, a middleware power failure or server crash may cause these problems.
3. Lack of rational and standardized database management tools. For example, redo logs in Oracle and database data files. Insufficient disk space and non-rotation of log files will trigger large performance problems and power outages.

Suggestion:

1. Reasonable capacity planning, including load and performance testing, is essential for optimizing the data environment and timely discovering problems.
2. If the Oracle database is used, ensure that the DBA Team reviews AWR reports on a regular basis, especially in the process of associating events and root cause analysis.
3. Use JVM thread storage and AWR reports to identify the cause of slow SQL running or use monitoring tools.
4. Strengthen the database environment for "operations" (disk space, data files, redo logs, tablespace, etc.) to monitor and alarm properly. If you do not do this, the client's IT environment will experience a lot of power outages and take a lot of time for Fault Repairs.

# P #

6. Specific application performance problems

The following are serious Java EE application problems. The performance of specific applications is summarized as follows:

1. Thread-safe code
2. The communication API does not have timeout settings.
3. I/O, JDBC, or relational API Resource Management Problems
4. Insufficient data cache
5. Excessive data cache
6. Excessive log records

7. Java EE middleware Optimization

Generally, Java EE middleware is enough, but it lacks necessary optimization. Most Java EE containers have a variety of solutions for your applications and business processes.

If appropriate adjustments and practices are not made, the Java EE container may be in a negative state.

Is a view and Check List Example:

8. Insufficient active monitoring

Lack of monitoring will not cause actual performance problems, but it will affect your understanding of the performance and health status of the Java EE platform. In the end, this environment can reach a break point, which may expose some defects and problems (JVM Memory leakage, and so on ).

In my experience, if you do not start monitoring, but run it for a few months or a few years, the stability of the platform will be greatly reduced.

That is to say, it will never be too late to improve the existing environment. The following are some suggestions:

1. Review existing Java EE environment monitoring capabilities and find areas for improvement.
2. The monitoring scheme should cover the entire environment as much as possible.
3. The monitoring solution should comply with the capacity planning process.

9. Hardware saturation of public infrastructure

This problem is often seen when too many Java EE middleware environments are deployed to the existing hardware with the JVM process. Too many JVM processes are a real performance killer for a limited physical CPU core. In addition, as the client business grows, the hardware needs to be considered again.

10. network latency

The last problem that affects performance is the network, which may occur from time to time, such as the failure of routers, switches, and DNS servers. It is more common to have regular or intermittent latency in a highly dispersed IT environment. The example in the following figure shows the latency between a WebLogic cluster communication in the same region and an Oracle database server.

Intermittent or regular latency can trigger important performance issues and affect Java EE applications in different ways.

1. Because of a large number of fetch iterations (Network incoming and outgoing), applications that involve data query problems in large datasets are very affected by network latency.
2. Applications are also subject to network latency when processing external system Big Data loads (such as XML data), resulting in a huge response interval when sending and receiving responses.
3. The replication process (cluster) of the Java EE container is also affected, and the Failover function (such as multicast or unicast packet loss) is at risk.

JDBC row data "prefetch", XML data compression, and data cache can reduce network latency. When designing a new network topology, you should carefully check this network latency problem.

I hope this article will help you understand some common performance problems and stress points. Each IT environment is unique, so the problems mentioned in this article may not be what you encounter, you can share your problems with us!

 

Reference: http://java.dzone.com/articles/top-10-causes-java-ee? Page = 0, 0

 

 

 

Reprinted please indicate the source
Http://blog.csdn.net/shimiso welcomes people of insight to join our technical exchange group: 173711587