For a project to withstand more pressure, each API needs to respond in the shortest time so that throughput is high.
In many cases, the development is not optimized at all, and when the pressure comes on one day, the system will fail.
Here’s the most common example:
Everyone goes to work by subway. The subway has several fixed entrances, and each entrance has several fixed gates that can be scanned to enter.
If the time for each person to scan and enter the station is controlled within two seconds, then a gate can pass 30 people in a minute. If you have one person who’s just dawdling there, and it takes 20 seconds, that’s the gate that can only handle 21 people a minute, the throughput goes down immediately.
This kind of life case is also true in the application world, and it is a principle that as long as there is a slow interface, it will affect the overall performance. Generally speaking, teammates should be very helpful, no Pig teammates.
Here’s a real case:
Is paddling to see the beauty, suddenly received an alarm, several interface response time is too long, up to tens of seconds. A lot of panic, guess something went wrong again.
The RPC interface of the commodity service is responding too slowly, and there is no call usage.
If you look closely, it’s not a very long operation, but the overall time is very long, so the request must be blocked.
Then I looked at the monitoring of the corresponding machine and found that the CPU was very high, almost 100%.
I looked at the GC situation, which is quite normal, and then I looked at the thread pool situation to find the reason.
The above is just a superficial phenomenon. There are several slow interfaces when an alarm is generated. During troubleshooting, the first one is selected and the other interfaces are ignored, thinking that the problem is the same.
The slow interface is called by the Job, and the service thread is full. Other interfaces are slow.
Optimization scheme:
- Adjust the time of scheduled tasks and try to execute them in the early morning
- If a service is provided separately, only the service is provided for the Job and the slave library, and the impact is minimized
- Optimize the performance of slow interfaces
About the author: Yin Jihuan, a simple technology lover, the author of Spring Cloud Micro-service – Full stack Technology and Case Analysis, Spring Cloud Micro-service Introduction combat and Progress, the founder of the public account Monkey World.
When you get something, don’t be stingy with your likes.
PS: Do you isolate interface calls of Job type? Current limit? Time adjustment? Leave a comment at the end of this article to discuss!