A case study on performance tuning of Java EE applications on GlassFish

Performance issues with Java EE applications are a very important issue for serious projects and products. In particular, enterprise-class applications, concurrent users, a large number of data transmission, business logic complex, occupy more system resources, so performance problems in enterprise-class applications become critical, it and the stability of the system has a direct link. More importantly, the performance of the application in the same task under the conditions of the use of less resources, to obtain a better user experience, in other words, is able to save costs and consumption, to achieve higher profits.

To get better performance, you need to tune your original system for performance tuning. Tuning is a relatively complex thing to do with Java EE applications running on GlassFish. Before tuning, you must recognize that the Java EE System, tuning is multi-level. The application of a Java EE is actually a small part of the entire system. Java EE programs developed by developers, whether JSP or EJB, run on the Java EE Application Server (Glassfish). The application server itself is written in the Java language and needs to run on top of the Java Virtual machine. Java virtual machines are simply an application of the operating system, and other applications, such as Apache, have no intrinsic difference to the operating system. But the operating system is running in a certain hardware environment, including CPU, memory, network card and hard disk and so on. At so many levels, each level of the factors will affect the performance of the entire system. Therefore, the tuning of a system, in fact, needs to be tuned at each level. Java EE application Performance tuning is not just about GlassFish, but also about the operating system and hardware, and the need to tune people with comprehensive knowledge and skills. These different levels of methods need comprehensive longitudinal effect, combined with flexible use, can quickly and effectively locate performance bottlenecks. The following are some specific case studies:

Memory leak problem

A Java EE application is running on a 8-CPU server. Running on line found the performance is not stable. Performance is getting slower as time increases. Through the operating system tool (MPSTAT), found that the system is very slow, only one CPU is busy, the other CPU is very idle. Therefore, it is suspected that the Java Virtual machine is often used for memory recycling, because when the virtual machine in memory recycling, some of the recovery algorithm can only run on one CPU. The Java Virtual machine's tool "Jstat" makes it clear that the Java virtual machine has a very high rate of memory recovery, almost every 5 seconds, and 2 seconds for each collection. In addition, the output through "Jstat" also finds that the memory freed each time is very limited and most objects are not recycled. This phenomenon is largely suggestive of a memory leak. Use the Java Virtual Machine's tool "Jmap" to get a current memory image. There are many (more than 10000) session objects found. This is not a normal phenomenon. Generally speaking, the session corresponds to a user's multiple visits, when the user exits, the session should be invalidated, the object should be recycled. When we learned about the session settings with the development engineer for the system, we found that when they deployed the application, the session's timeout time was set to 50 minutes and no logout interface was provided. With this setting, the data for each session is saved for 50 minutes before being recycled. According to our suggestion, the system provides a logout link and tells the user that if you quit the application, you should click on the logout link and change the session's timeout time to 5 minutes. Through a few days of testing to prove that the problem of leakage is resolved.

Database connection Pooling Issues

A financial application runs on the Java EE server, which is connected to the Oracle database in the background. The system stops responding when the number of concurrent users is more than 100 people. The Process monitoring tool at the operating system level found that the process was not killed or hung, while CPU usage was almost Nil. So what causes the system to stop responding to user requests? We use the Java Virtual Machine tool (kill-3 pid) to dump all current thread states, discovering that most of the Java EE server's processing threads are waiting for the connection of the database connection pool, while the threads that have obtained the database connection are blocked. The database administrator needs to check the state of the database and finds that all of the connected sessions are in a deadlock state. Obviously, this is because of deadlock operations on the database side, blocking requests that have database operations, and consuming connections from all database connection pools. Subsequent requests are blocked on the connection pool if they are also to get a connection from the connection pool. After resolving the problem of database deadlock, the performance problem is solved.