Pierre-Hugues Charbonneau (nicknamed P-H) is a senior IT consultant and System Architect at CGI Canada. Recently, he published the article titled "top 10 causes of Java EE Enterprise Performance problems"Article, Lists the factors that have the greatest impact on the performance of Java EE Enterprise systems, and makes good suggestions.
In this paper, the P-H first pointed out that in the design and implementation of Java EE related technology, performance problems is one of the biggest challenges we face. For it architects and Java EE developers, it is important to understand the client environment and ensure that the proposed solution not only meets the increasing business needs, it also ensures the scalability and reliability of the production environment for a long term.
Next, he listed the causes of Java EE performance problems encountered in the past decade and made some high-level suggestions. Top 10 reasons include:
- A proper capacity plan is missing.
- The specification of the Java EE middleware environment is insufficient.
- Excessive Java Virtual Machine garbage collection.
- Too many or very poor integration with external systems.
- There is a lack of appropriate database SQL optimization and capacity plans.
- ApplyProgramSpecific performance issues.
- Thread SecurityCode.
- Communication API timeout is missing.
- I/O, JDBC, or relational persistent API resource management issues.
- A suitable data cache is missing.
- Excessive data cache.
- Excessive logging.
- Java EE middleware Optimization.
- Insufficient active monitoring.
- Hardware saturation on general basic devices.
- Network latency.
To address these issues, the P-H's recommendations include:
- the project team should spend enough time creating a proper operation model for the Java EE production environment.
- find the balance between Java EE middleware specifications, such as the flexibility provided by the business and O & M teams to cope with the running interruption.
- avoid deploying too many Java EE applications in a 32-bit JVM. The middleware design can process multiple applications, but the JVM may not.
- if you want to replace a 32-bit JVM with a 64-bit JVM, you must have an appropriate capacity plan and performance test to ensure that the hardware supports it.
- make sure that your monitoring program has a good understanding of JVM garbage collection.
- remember that issues related to garbage collection may not be found during development or functional testing.
- suitable capacity plans include load and performance tests. It is important to optimize the database environment. It can locate problems at the SQL level.
- if you use the Oracle database, make sure that the DBA Team reviews the AWR report.
- use the JVM thread dump and AWR reports to locate slow SQL statements and use the selected monitoring tool to do the same job.
- make sure that you spend enough time enhancing the running capability of the database environment (disk space, data files, redo logs, tablespace, and so on), and make appropriate monitoring and warnings.
- review your current Java EE environment monitoring capabilities and find opportunities for improvement.
- your monitoring solution should cover the end-to-end environment as much as possible, including active warnings.
- the monitoring solution should be consistent with the capacity planning process.
