Problems and analysis in JMeter performance testing. How many problems have you encountered?

Common performance test analyse

1、 System resource problems 
CPU/ Memory / disk / The Internet ...

2、 Language / Code ：
JVM/PHP-fpm  ...etc

3、 Frame question ：
Sprint Boot / Baidu RPC...

Copy

Single point of service performance problems

1、CPU load 
2、 Memory leak 
3、 disk IO
4、 The Internet IO
5、JAVA Full GC
6、TCP The number of connections 
7、 The worker thread is full 
.....

Copy

Case study 1： A stress test , Server side CPU Soar to full ,CPU Computational

TOP -H -p pid
Pstack pid
Trace -p pid

 Code logic problems ：
 Synchronous resolution interface , Match the returned content in a regular way , But because the returned content is too large , Lead to CPU soaring . Regular , Big data JSON serialize / Deserialization 

 In addition, the deadlock problem can be tuned in a similar way 
CPU Not high , But the service response is time-consuming , Request to pile up ;

Copy

Case study 2： A stress test , System CPU And other indicators are normal , However, occasional intermittent time requests are particularly time-consuming

JVM GC problem ：
Full GC Stop the world
 Reduce Full GC Time , Decrease in the elderly generation 

Copy

Case study 3： A stress test ,php Program ,php-fpm Memory growth ,OOM Cause the service to hang up

 Check the cause , Using a third party so Plug in JSON analysis , But a third party so The plug-in has a memory leak problem .

Max-request,fast-cgi  Restart after fixing the number of requests 

Copy

Case study 4： A pressure measurement ,CPU/ Memory / The Internet And other indicators performed well , But the response takes a long time

 Monitor disk view IO abnormal , The trace discovery log level is set to Debug, A lot of log printing is a drag on performance 

 Synchronous log , May be a potential performance killer 

Copy

Case study 5： A stress test ,CUP/ Memory / The Internet / disk All indicators performed well , But the response time is very long

 see Nginx  journal , Find out  request_time longer , however  upstream_response_time  Actually short .

Copy

Case study 6： A pressure measurement , The same concurrency TPS, But the early performance is good , Post database CPU soaring

 Pressure measurement will generate a large amount of data , Data growth will lead to loss of performance 

 The pressure measurement data is unreasonable , This causes the unified device to associate multiple users , There are no restrictions on the server in Inquire about 

 Unreasonable paging , No coconut tree limit, As a result, all the newly added data in the database will be queried 

Copy

Case study 7： A stability test , Big concurrent TPS, Good early performance , Slice cache , A large number of database penetrations are simulated at a single point of cache failure

 Cache unreasonable fragmentation strategy , Use division mode . Cause a large number of cache unified time invalidation .

 Unreasonable load balancing algorithms will have similar problems .

 The consistency of the HASH Fix this cache problem 

Copy

Case study 8： A stability test , If HTTP The inlet flow is only 100% QPS, But downstream RPC Service gossip

 List of merchants ,for Loop call downstream to solve , Resulting in a request hundreds of times larger .

 Use Batch The interface reduces pressure ,Batch Interfaces may bring hidden functional problems 

Copy

Publisher ： Full stack programmer stack length , Reprint please indicate the source ：https://javaforall.cn/100683.html Link to the original text ：https://javaforall.cn