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

This article mainly introduces "nginx metrictag big data interface response slow how to troubleshoot and deal with", in the daily operation, I believe that many people in the nginx metrictag big data interface response slow how to troubleshoot and deal with the problem, the editor consulted all kinds of data, sorted out a simple and useful method of operation, hope to answer the "nginx metrictag big data interface response slow how to troubleshoot and deal with" the doubt is helpful! Next, please follow the editor to study!

I. problem phenomenon

Timeout errors often occur when platform calls queryMetricTagRel.

Note: the response size of this interface is 118m, which requires high network performance.

2. Troubleshooting and handling of problems 1. Confirm whether the interface itself is slow in response.

By troubleshooting the nginx log:

The average response time of the two machines in the wuhan room is about 30 seconds, and the response time of the two machines in the beijing room is almost about 3 seconds. It can be seen that the timeout is caused by accessing the wuhan server service.

Since the nginx gateway is deployed in the beijing computer room, and the two services in the beijing computer room are accessed very quickly, it can be seen that the timeout is mainly due to the high time-consuming access to wuhan services by beijing's nginx.

2. Solve

Solution one: remove the influence of the network. Since there is a problem with the wuhan to beijing network, just get rid of the two machines in the wuhan room (it is best if beijing can apply for two more machines, but there are no more machines).

But note: after removing the wuhan machine, all requests are forwarded to both beijing machines.

Observation: after the removal of the two machines in wuhan, it is found that the request has indeed become faster, but after a while, another request has timed out, which has already been accessed in the same region, and the timeout will not be a network problem, so what else may it be? The answer is the machine's network card!

Take a look at the monitoring of the machine's network card: it is found that at about 14: 20, the traffic has risen, which is normal, the traffic is up to 1.6G at most, but the normal should be about 1.8g, so consider whether the machine's network card is speed-limited?

With this doubt, I consulted the equipment service provider that it is true that for the limited flow of machines, the speed limit of 1.6G per machine will cause the excess request response data to be unable to be transmitted in time, which will naturally be slow.

And the network card traffic reaches the upper limit, which may affect the ingress requests, causing many requests to slow down.

Solution two: upgrade the network card. In order to solve the current limit of the network card, we upgrade the network card to 3.2G/ seconds.

However, it is found that there are still timeouts sometimes, and no accident should be caused by network restrictions.

Solution three: compression. Since the interface response content will have network card, network and other problems, can the response data be compressed? The answer is yes. This project is built by spring-boot. The framework provides a mechanism to compress the response data and a way to configure it:

Server.compression.enabled=true # Open the compression mechanism server.compression.mime-types=application/json # to compress the json response format to gzip

But the above will only take effect if the client specifies how to accept gzip, that is, Accept-Encoding: gzip

After a simple test, after gzip, the size after compression is 1 / 8 of that before compression, which is considerable and greatly reduces the consumption of the network side.

Effect: before compression: 129KB, time-consuming 532ms

After compression: 15KB 564 Ms, it takes about the same time (when it comes to compression calculation and decompression calculation, it costs CPU), but the Size is reduced nearly 10 times.

Response: Content-Encoding: gzip indicates that the server has been compressed by gzip

At this point, the study on "how to troubleshoot and deal with the slow response of nginx metrictag big data interface" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.