How to test and optimize Java EE Performance

Performance testing objectives

Performance testing is different from functional testing. It is not a right or error test, but a measure of speed and slowness. Before conducting a real performance test, you must first clarify the objectives:

1. Under the specified hardware conditions, the larger the number of concurrent requests, the better the response time. The product manager proposes how many concurrent requests are required and how fast the response time is.

2. After the maximum number of concurrent tasks and the corresponding response time are obtained by testing the hardware. If you increase your hardware investment, what kind of performance improvement will be paid off? Scalability)

The hardware conditions include cpu, memery, I/O, and network bandwidth.

Benchmark Test Benchmarking in Performance Testing

Similar to functional testing, you must design test cases for performance testing. The difference is that you must perform a benchmark test before you officially start your business test cases. Why? In fact, you need to measure your hardware capabilities first. Otherwise, if your test results are not good, how do you know whether the hardware is slow or your software is faulty. These hardware tests include:

1. network bandwidth test. You can copy large files to test the maximum bandwidth of your network.

2. cpu. You can use complicated algorithms to measure the cpu speed.

3. memery. You know the size of memery.

4. IO. You can also test it by copying large files.

In the subsequent optimization process, can these benchmark test cases be used to determine whether the changes have been completed after modification.

Design Your Business Test Cases

The ideal test case is to imitate the real world as much as possible, which is often not possible, especially for new products. You can first record some of the most commonly used cases as the starting point.

In addition, the concept of concurrency needs to be clarified. Concurrent users usually refer to users online at the same time. These users can use different functions of your system. Note that they are not saying that everyone is doing the same thing. A concurrent request to a transaction refers to the concurrent call of a request.

For the latter type of concurrency, you often need to calculate which of the following tasks is concentrated when the number of users is the largest. This request must be fast enough.

After these two test cases are designed, they will become a yardstick for measuring the effectiveness of your improvement in the subsequent optimization process.

Performance Tuning

Performance Tuning starts from the underlying layer, basically from the OS to the JVM, Cache, Buffer Pool, SQL, DB Schema, and algorithm.

Don't change too much at a time. change a bit and test it. This is a slow task and requires patience.

When executing the test, you should also pay attention to the same process. After the system is restarted, warm up before starting the real test. Otherwise, you will find that your test results are very different, not sure.

Also, pay attention to the capabilities of your client, such as JMeter, which requires a lot of memory. Do not use the client because it may be a problem with your system.

When testing and tuning, you need to use some monitoring tools such as JConsole to monitor the system status and find the System Bottleneck. The so-called bottleneck is the slowest part, it is also often seen that 100% is full. For example, your memory or cpu usage is exhausted. If the cpu and memory are not used up, they are waiting for a resource. In this case, you need to use the profile tool, such as JProfile and YourKit.

Use performance monitoring logs

Because the performance problem is not easy to reproduce, when the product environment encounters performance problems, if it is a data problem, maybe when you copy the product data to your testing environment, then we can reproduce and improve the slow query. However, if it is a problem of concurrent users or runtime environments such as the network, it is difficult for you to reproduce it. At this time, if you can see the key slow response methods through the log, it may help you quickly find the problem. The following code can help you do this for your reference only:

 
 

  
  
import org.slf4j.Logger;   
  
  
     
  
  
  public class TraceUtil {   
  
  
      final Logger logger;   
  
  
      final long threshold = 1000;   
  
  
      private long begin;   
  
  
      private long offtime = 0;   
  
  
      private String threadInfo;   
  
  
      private String targetId;   
  
  
     
  
  
      public TraceUtil(Logger logger, Thread thread, String targetId, long begin) {   
  
  
          this.logger = logger;   
  
  
          this.threadInfo = thread.getId() + "-" + thread.toString();   
  
  
          this.targetId = targetId;   
  
  
          this.begin = begin;   
  
  
      }   
  
  
     
  
  
      public void trace(String targetEvent) {   
  
  
          long duration = System.currentTimeMillis() - begin;   
  
  
          long increment = duration - offtime;   
  
  
          offtime = duration;   
  
  
          float percentage = (float) increment / (float) duration * 100;   
  
  
          if (duration > threshold && percentage > 20) {   
  
  
              logger.error(   
  
  
                      "Response time is too large: [{}], {}/{} ({}), {}, {}",   
  
  
                      new String[] { threadInfo + "", increment + "",   
  
  
                              duration + "", percentage + "%", targetEvent,   
  
  
                              targetId });   
  
  
          }   
  
  
     
  
  
      }   
  
  
     
  
  
  }  
 
 

Use JVM MXBean to find the blocked point

When you find that the JVM occupies a high cpu and the response time is slow, it is very likely that it is dragged by slow devices such as IO or network. It may also be that a synchronization point synchronization method or object in your method has become a performance bottleneck. At this time, you can use the monitor API provided by JVM to monitor:

 
 

  
  
<%@ page import="java.lang.management.*, java.util.*" %>   
  
  
    <%!   
  
  
        Map cpuTimes = new HashMap();   
  
  
        Map cpuTimeFetch = new HashMap();   
  
  
    %>   
  
  
       
  
  
    <%   
  
  
    out.println("Threads Monitoring");   
  
  
    long cpus = Runtime.getRuntime().availableProcessors();   
  
  
    ThreadMXBean threads = ManagementFactory.getThreadMXBean();   
  
  
    threads.setThreadContentionMonitoringEnabled(true);   
  
  
    long now = System.currentTimeMillis();   
  
  
    ThreadInfo[] t = threads.dumpAllThreads(false, false);   
  
  
    for (int i = 0; i < t.length; i++) {   
  
  
        long id = t[i].getThreadId();   
  
  
        Long idObj = new Long(id);   
  
  
        long current = 0;   
  
  
        if (cpuTimes.get(idObj) != null) {   
  
  
            long prev = ((Long) cpuTimes.get(idObj)).longValue();   
  
  
            current = threads.getThreadCpuTime(t[i].getThreadId());   
  
  
            long catchTime = ((Long) cpuTimeFetch.get(idObj)).longValue();   
  
  
            double percent = (double)(current - prev) / (double)((now - catchTime) * cpus * 1000);   
  
  
            if (percent > 0 && prev > 0) {  
  
  
    out.println("<li>" + t[i].getThreadName()+"#"+t[i].getThreadId() + " Time: " + percent + " (" + prev + ", " + current + ") ");  
  
  
    String locked = t[i].getLockInfo()==null?"":t[i].getLockInfo().getClassName();  
  
  
    out.println(" Blocked: (" + t[i].getBlockedTime() + ", " + t[i].getBlockedCount() + ", " + locked + ")</li>");  
  
  
    }  
  
  
        }   
  
  
        cpuTimes.put(idObj, new Long(current));     
  
  
        cpuTimeFetch.put(idObj, new Long(now));   
  
  
    }   
  
  
    %> 
 
 

Synchronization is a major performance bottleneck

Through monitoring, it is found that a large number of thread blocks are in a synchronous method, so that the cpu is not busy. When you find that performance is not good, IO, network, and other slow devices are not a problem, you have to check whether synchronizae is used at a critical point ). Sometimes some method in the third-party jar of your application is synchronized. In this case, it is difficult to find the problem. You can only check whether the referenced method is synchronized when writing code.

Read more

1. Java run-time monitoring series articles, which systematically explain the jvm monitoring

2. Performance Tuning the JVM for Running Tomcat: This article lists several key jvm parameters related to tomcat Performance.

3. A book explaining Java Performance systematically: Java Performance

4. insideApps: A transaction-level open-source Java EE performance monitoring software. It is expected to be stored in the product environment and monitor and analyze the product performance without affecting the system performance. Good idea.

5. ManageEngine, a powerful monitoring software, has a free version.