Closed lemkepf closed 5 years ago
@romandres sorry, missed this one earlier. I would not expect App Insights to affect cold start. If you see this consistently (fast without, slow with), can you open a separate issue so we can better track?
I am going to add the information I found on this topic:
To speed up the cold start process, run your functions as a package file when possible. https://docs.microsoft.com/en-us/azure/azure-functions/run-functions-from-deployment-package
Azure Functions Pack (JS) packs dependencies for fast cold start https://github.com/Azure/azure-functions-pack
A blog on cold starts https://blogs.msdn.microsoft.com/appserviceteam/2018/02/07/understanding-serverless-cold-start/
@davidebbo I too have this problem. To me, the hybrid approach doesn't sound too great because I'd need to buy dedicated VMs for most of my expected consumption (with low latency) and use serverless functions only for the bursts (and of course the bursts will take a long time). This almost defeats the purpose of going truly serverless. Also, I was content with using the Web API framework as Functions seems to lack quite a bit of features, but it was a better choice to shave off costs. If I'm going to use actual VMs, I'd rater go back to Web APIs and have access to an actual HTTP pipeline and things like [Authorize]
attributes.
Having said that, I may be misunderstanding the hybrid approach here. Why not use a dedicated VM only for the bursts instead? If there are no warm instances available on the consumption plan, then use the dedicated VM while the infrastructure warms up another instance behind the scenes.
@adrianknight89 I'm no longer in this project, so I will let others respond (e.g. @paulbatum). But this is an old issue and things have improved quite a bit since. I suggest that you add details on your scenario: e.g. what language, what OS, what runtime version, are you using Run As Package, what kind of timing you are observing, etc...
@paulbatum I’m using C#, Windows 10 (idk why OS matters though), v2, and zip deployment on the consumption tier.
My biggest complaint at the moment is every time I publish new changes (which I do very frequently), everything seems to be deployed to another server, and I incur the full cold start penalty.
I’ve read somewhere that v2 wasn’t as optimized as V1, but this was when it was still in preview. Do you still believe v2 lacks optimization compared to the older version?
As for dependencies, this is probably not the greatest idea, but why don’t you install some of the most popular libraries on your servers (and say the last 5-10 releases of each) and fallback to copying the files on the fly in case they don’t exist on the destination server? A lot of people use Newtonsoft, EF, Azure client SDKs, etc. If the source and the target have the same dependencies and versions, you could skip moving them over the wire.
I'm also experiencing this issue when using Azure function as http webhook. When a cold start happens, the caller (Azure Monitor Log Search Alert) times out and retries the call, resulting in the function being called twice. The function is a compiled C# function using V1 runtime and deployed using WEBSITE_RUN_FROM_PACKAGE. It's unfortunate that the only solution seems to be switching to standard App Service plan away from Consumption mode
@adrianknight89 By OS, David meant whether you're running your function app on Windows or Linux, as there are some important differences in terms of how cold start is handled between the two.
Typically, changes are not deployed to a new server/vm. If you make a change locally, deploy (such as with VS or VS Code), then hit the endpoint, most of the time that request will be routed to the same server that was running your app prior to deployment.
Instead, what I suspect you are hitting is the fact that when you make an assembly change or an app setting change, we restart the process to pick up that change, and when do this process restart, we do not reuse our 'placeholder' infrastructure that is used to optimize normal cold starts. This is a possible area of improvement that we have not had a chance to investigate yet. Let me try to chat with some folks and report back. We might want to file a new issue to discuss this scenario because it is really a "development" cold start instead of a "production" cold start.
Regarding common libraries - there are several factors that impact cold start time, but getting the necessary libraries onto the target server is not really one of them. These type of optimiziations can significantly help with build time (for example, having a cache of nuget modules to make nuget install complete faster) but that is a different issue.
I'm experiencing cold startup times exceeding 20 seconds in Consumption plan for my trivial C# function. I ping it every 5 minutes using App Insights to keep it warm, but it still shows sporadic >20s responses. What do I do?
@ogvolkov I've started to experience the same issue too.
I have an availability test, that pings my API Management, that calls my AF v2
BTW, the same function, 10 days ago showed 10s cold start, instead of 20seconds
Normally, AF host is killed after 20 minutes of inactivity.
When warmed up , I can see a behavior, when 20s cold start happens every 60-70 mins, starting from April. Before that it was, around 10 secs from time to time.
Which looks like that Consumption Plan was changed, as now we have Premium Plan
This issue has been opened for a while and has covered a few different scenarios over the years. To make sure we're investigating new issues reported (as they won't have the same root cause), please open new issues so we have the right context and things are not missed.
Closing this.
This is our first use of Azure Functions and we are happy with the idea so far. We have a couple functions setup that will get hit randomly throughout the day so it will never be called warmed up. The issue that we are having is the cold startup time is 30s+.
Here is an example: Monitor logs says that function was only 2,640ms running time. On our end we saw 30.30 seconds. This request happened 18:34 on Thursday, October 27, 2016 (UTC).
If we call it again right after the first it's a 200ms response time. If we wait 10 minutes it'll take another 30+seconds again.
I've created a dummy app name if you want to look into this: dumm2345
Is this 30 second startup time expected?