Apparently, Azure App Service has a 230-second timeout.. However, when I look at my logs in App Insights' Request table, I see requests to my .NET API with 400-500 seconds duration that resulted in 200. On the other hand, I do see some 500s where the duration is over 230 seconds.
So my question is why do I see this discrepancy?
I can think of two theories:
Either, the 230 seconds is not always enforced.
Or the logs in the Request table in App Insight, show the information from what is returned from the app, and NOT the actual user experience. i.e. if, for example, my backend takes 300 seconds and returns a 200, then that's what I see in logs. However, the user got a 500 after 230 seconds.
Answering my own question in case anyone ran into this ...
I did some testing and confirmed that the 230s timeout is indeed enforced, i.e. the caller of the API would get a 500 after 230s if the API hasn't returned a response yet. However, the duration field in the logs' Request table indicates the time the app took to return a response, i.e. if the API takes 5 minutes to return a 200, the caller would get a 500 right after 230 seconds, however, in the logs, you'd see the request took 5 minutes.
That timeout is enforced on load balancer and its documented. But app service will continue to process your request it will only affect your client.
If you need to know when something completed then probably have a look into Asynchronous Request-Reply Pattern
Related
We have a service which pings our EP1 Premium service and yesterday we received 3 client side timeout errors after 2 minutes of waiting. When opening the trace in App insights, these requests which time out are not even logged and have no trace of ever being received Azure side, and therefore stay unanswered. By looking at the metrics provided in the Azure Functions app, I found out that 1-2 minutes after the request has been sent, the app loses all its ability to work as its Total App Domains falls to 0 as well as all connections, threads and so on and this state lasts until the next request is received, therefore "skipping" the request that happened beforehand. This is a big issue as I need to make sure requests get answered in a timely manner.
The client service sent HTTP requests to the Azure Functions app expecting an answer, only to time out while the Azure-side doesn't have any record of ever receiving the request.
I believe this issues is related to Consumption Plan of Azure Functions called Cold Start behaviour. The "skipping" mechanism is explained below:
Apps may scale to zero when idle, meaning some requests may have additional latency at startup. The consumption plan does have some optimizations to help decrease cold start time, including pulling from pre-warmed placeholder functions that already have the function host and language processes running.https://learn.microsoft.com/en-us/azure/azure-functions/functions-scale#cold-start-behavior
Please also consider of having look on this article, which explains the behaviour. https://azure.microsoft.com/en-us/blog/understanding-serverless-cold-start/
I have deployed a .Net Core API to Azure as an App Service.
I have set the Always on feature to true.
When I log the requests, I see that Azure Always on requests are coming every 5 minutes.
My usage with API is HTTPS but Always on requests are sending with HTTP. I don't know if this is the case
For the first request, it is sometimes 10 seconds, but after the first request, it is around 100ms.
What is missing here?
I have logged the durations:
There are quite a few reasons why this might be the case:
You're connecting to resources that take time connecting to the first time
Some information is being cached and needs to be read the first time
There is initialization code present
Lazy instantiation of (static/singleton) instances
... other ...
Add some logging to your application, maybe enable Application Insights if you haven't done so already and go try to find the culprit.
According to Dialogflow Docs
The response must occur within 10 seconds for Google Assistant applications or 5 seconds for all other applications, otherwise, the request will time out.
Is there any way we can increase this without going for an API WebClient approach?
I am using the dialogflow web demo as web client and need to make a call to node service to fetch data from a cloud dB.
The following limitations apply to your response:
The response must occur within 10 seconds for Google Assistant
applications or 5 seconds for all other applications, otherwise the
request will time out.
The response must be less than or equal to 64 KiB in size.
How ever there will be,
Webhook call failed. Error: DEADLINE_EXCEEDED
So you must complate your task within 5 second. and if you are not able to fetch data within 5 second then there is something wrong with your infrastructure.
Dear Instagram developers team,
Our team is currently in the design phase of a connector to Instagram API for our application.
We bumped into a few questions related to the Instagram API limits.
Would you consider the following scenario as a bad practice?
use all 60 per hour calls for an endpoint until connector receives a 429 response code form the Instagram API
when the first 429 response is received the connector stops calling the Instagram API for 5 minutes, then try again
If the response was successful, continue from step #1, if not - increase 'sleeping time' by 5 minutes each attempt until the call is
successful and then continue from step #1
How many calls that return 429 code our connector can make in an hour
so its behavior would not be considered spammy? Can we make lets say
20 such calls in a row? The question raised because of the very last
sentence on the limits page.
You may also receive responses with an HTTP response code of 400 (Bad Request) if we detect spammy behavior by a person using your
app. These errors are unrelated to rate limiting.
Per hour limit means that at the beginning of an hour the entire limit is
reset or it means that once an API call is made, the available limit will be increased by one after one hour? The second scenario means that if I made 30 calls in one minute and then another 30 after half an hour, when one hour plus one minute passes from the first call only 30 calls will be available.
Is there a way to increase limits for POST or DELETE calls?
Thank you
I have a ajax that calls a function.
This function spend 5 minutes to complete.
When I run in my machine, it's everything ok.
But when I run in my deployed web site in azure, the request return with error 500 when past 3.5 minutes. But it's continue running and complete the work, I see in the database.
The response is blank.
Any help?
Thanks!
You can change approach and use web sockets.
5 minutes is a long time to hold a connection, a lot can happen in 5 minutes,
Different approach would be to return a guid before you start the process and make a lull request from the client every 10 sec or so until the process state is changed to finished and you can return the result.
Good luck.