azure-How to troubleshoot application Gateway return HTTP Code 502 or client to get Application Gateway response slow problem (i)

Problem description

After initial troubleshooting, the application gateway itself works fine and also excludes the latency of the Azure platform network. The behavior that occurs is usually a partial URL response is normal, a partial URL response is slow, or HTTP Code 502 is returned.

Problem analysis

1. Determine application access and response by analyzing access logs (see: Backend Health, diagnostic logs, and metrics for application Gateway) for information on how to enable and get diagnostic logs.
2. Compare the access logs of the backend Web server with a timestamp or URL to query the response of the same request on the application gateway and back-end Web server.
3. If you see in the Access log of the application gateway and the back-end WEB server that the value in partial URL access is timetaken unusually large relative to the request content (for example, the request content is only dozens of K, but the response time is more than 5 seconds), the backend server responds slowly.
4. If the application Gateway records HTTP Response Code 502 in the access log of the backend Web server and returns HTTP code 200, pay careful attention to the timestamp and discover that the back-end server's Http Response Code 200 responds more time than the application network The Http Response Code 502 that logged this URL access is 1 seconds or longer.

The above analysis process can be determined that this problem is related to the slow response of the backend Web server.
This includes two possibilities:

1. The WEB server is working abnormally.

   If you are an IIS-based WEB server, you can track a request for slow or unusual response by turning on the failed request Tracing (FRT) feature, as you can refer to another article: How to troubleshoot application Gateway return HTTP Code 502 or client to get the application The problem of slow response of Sequential Gateway (II.)

2. The WEB server works fine, but it takes a long time to apply the logical operation.

   Because the application gateway has a timeout of 30 seconds in the default HTTP settings, and after 30 seconds, if the backend Web server does not respond to this request, the application Gateway considers the request session to time out and returns to the front-end client HTTP Code 502.

HTTP settings time-out configuration such as:

Workaround

There are two ways to solve these problems:

1. The appropriate extension of the application gateway's HTTP settings time-out (the longer it takes for the application gateway) to allow the application gateway time-out to match (slightly more than) the maximum response time required for the application of the backend Web server to respond properly.
2. If you do not want to increase the timeout for the HTTP settings of the application gateway, and the keep-alive mechanism is configured in the WEB application, it is recommended that you do not set it to exactly 30 seconds, but more than 30 seconds, so that the application gateway does not receive a response from the Web server within 30 seconds so t Imeout and returns the HTTP Code 502 to the front-end client.

In both cases, the WEB server is working properly, but it takes a long time to apply the logical operation.
As mentioned above may be the back-end Web server itself is working abnormally, if it is an IIS-based Web server, you can turn on the failed request Tracing (FRT) feature to track a slow or abnormal response request, refer to another article: How to troubleshoot the application gateway Return HTTP Code 502 or client to get application Gateway slow response Problem (ii)

Azure-How to troubleshoot application Gateway returning HTTP Code 502 or clients getting Application Gateway response Slow (i)