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

This article mainly explains "how to test and tune Java EE performance". The content of the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "how to test and tune Java EE performance".

The goal of performance testing

Performance testing is different from functional testing. It is not a test of right or wrong, but a measure of speed and slowness. Be clear about the goals before you do any real performance testing:

1. Under certain hardware conditions, the larger the number of concurrency that can be supported, the better, and the faster the response time, the better. How much concurrency needs to be achieved and how fast the response time is required should be put forward by the product manager.

two。 Under the determined hardware conditions, after the test obtains the number of concurrency and the corresponding response time. What kind of performance improvement can you get if you increase your hardware investment? (system scalability and scalability testing, Scalability)

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

Benchmark Benchmarking in performance testing

Similar to functional testing, performance testing requires the design of test cases, except that you need to benchmark before you officially start your business test case. Why? In fact, it is necessary to measure the ability of your hardware first, otherwise, if your test results are not good, how do you know if the hardware is slow or your software is wrong? These hardware tests include:

1. Network bandwidth test, you can test the bandwidth of your network by copy large files.

2. Cpu, you can use more complex algorithms to measure the speed of cpu

3. Memery, there is no need to test this. You know the size of memery.

4. IO, which can also be tested by copy large files.

These benchmark cases can also be used to measure whether you have really changed for the better later in the tuning process.

Design your business test cases

The ideal test case is to mimic the real world as much as possible, which is often not possible, especially for new products. You can start by recording some of the most commonly used and typical case for users.

In addition, the concept of concurrency needs to be understood. Concurrent users, usually those who are online at the same time, can use different functions of your system. Note that this does not mean that everyone is doing the same thing. A concurrent request to a transaction refers to a concurrent call to a request.

For the latter type of concurrency, you often need to calculate what everyone is focused on when the number of users is *, and this request must be fast enough.

After designing these two test cases, they will become a yardstick to measure the effectiveness of your improvements in the subsequent tuning process.

Performance tuning

Performance tuning starts at the bottom, basically from OS to JVM,Cache,Buffer Pool, SQL,DB Schema, and algorithms.

Do not change too much at a time, change a little bit, test it, this is a slow effort, it takes patience.

Also note that to follow the same process, the system needs to warm up before starting the real test after rebooting, otherwise you will find that your test results are very different and uncertain.

Also, pay attention to the ability of your client, such as JMeter, which needs memory very much. don't mistake it for a problem with your system just because the client can't.

When testing and tuning, you need to use some monitoring tools such as JConsole to monitor the status of the system and find the bottleneck of the system. The so-called bottleneck, even the slowest part, is often 100% full. For example, your memory or cpu has been exhausted. If cpu and memory are not used up, they are waiting for a resource. At this point, you need to use profile tools to find it, such as JProfile,YourKit.

Take advantage of performance monitoring log

Because performance problems are not easy to reproduce, when you encounter performance problems in the product environment, if it is a data problem, maybe when you copy the product data into your test environment, you will be able to reproduce slower queries and improve them. But if it's a problem with concurrent users or a runtime environment such as the network, it's hard to reproduce it. At this point, if you can see the key slow response methods through the log, it may help you find the problem quickly. The following code can help you do this, for 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 the MXBean of JVM to find the point of blocked

When you find that JVM takes up a high cpu and the response time is slow, it is likely to be held up by slow devices such as IO or the network. It is also possible that a synchronization point in your method (synchronization method or object) becomes a performance bottleneck. At this point, you can use the monitor API provided by JVM to monitor:

0 & & prev > 0) {out.println ("" + 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 + "));}} cpuTimes.put (idObj, new Long (current)); cpuTimeFetch.put (idObj, new Long (now));}% >

Synchronization is a major bottleneck in performance

Through monitoring, it is found that a large number of threads block on a synchronous method, so cpu does not work. When you find that performance is not improving, and slow devices such as IO and the network are not a problem, you have to check to see if synchronizae is used at some key point. Sometimes it may be that a method in the third-party jar you are applying is synchronized, in which case it is difficult to find the problem. You can only see if the method you reference is synchronized when you write the code.

Thank you for reading, the above is the content of "how to test and tune Java EE performance". After the study of this article, I believe you have a deeper understanding of how to test and tune Java EE performance, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.