Cold start time took more more than 10 secs with C# compiled + "Run from package" for Azure function v2 #3965

RudyLu · 2019-01-16T01:39:57Z

Investigative information

Please provide the following:

Timestamp: 2019-01-16 01:01:11.130
Function App version (1.0 or 2.0): 2
Function App name: test-vs-func
Function name(s) (as appropriate): test_vs_func
Invocation ID: 24594d05-f1bb-4840-8439-f0227fb02678
Region: East Asia

Repro steps

Provide the steps required to reproduce the problem:

Compiled the sample app with visual studio for mac.
Change function app to "Run from package"
Zip it and do the zip deployment.
az functionapp deployment source config-zip -g rudy-dev -n test-vs-func --src csharp.zip

Expected behavior

I would expect that C# compiled + "Run from package" would have the lowest cold start time.

Actual behavior

The cold start time is even worse than C# without "Run from package" and C# script.

Known workarounds

no

Related information

Provide any related information

Programming language used C#
Bindings used: none
I can provide the package I uploaded if that helps,
https://drive.google.com/file/d/1FzEm9QLNeOj5eJlv_U64kuRpw-nIOb8f/view?usp=sharing

Source

using System;
using System.IO;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;
using Microsoft.Azure.WebJobs.Host;
using Microsoft.Extensions.Logging;
using Newtonsoft.Json;

namespace test_vs_func
{
    public static class test_vs_func
    {
        [FunctionName("test_vs_func")]
        public static async Task<IActionResult> Run([HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)]HttpRequest req, ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");

            string name = req.Query["name"];

            string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
            dynamic data = JsonConvert.DeserializeObject(requestBody);
            name = name ?? data?.name;

            return name != null
                ? (ActionResult)new OkObjectResult($"Hello, {name}")
                : new BadRequestObjectResult("Please pass a name on the query string or in the request body");
        }
    }
}

The text was updated successfully, but these errors were encountered:

safihamid · 2019-02-28T18:05:00Z

Please take a look at our docs here: https://docs.microsoft.com/en-us/azure/azure-functions/run-functions-from-deployment-package

"When running a function app on Windows, the external URL option yields worse cold-start performance. When deploying your function app to Windows, you should set WEBSITE_RUN_FROM_PACKAGE to 1 and publish with zip deployment."

RudyLu · 2019-03-10T17:03:00Z

I think I already did this with these steps,

Change function app to "Run from package"
Zip it and do the zip deployment.
az functionapp deployment source config-zip -g rudy-dev -n test-vs-func --src csharp.zip

Can you suggest any specific step that I might miss?
Or what's the expected cold start time for a simplest hello world function?

safihamid · 2019-03-11T23:10:45Z

You might be hitting this issue: Azure/azure-functions-core-tools#1086

safihamid · 2019-03-11T23:12:57Z

Also we are tracking cold start improvements with these two issues:

[V2 cold start] Enabling AppInsights is increasing functions cold start by 500-800 milliseconds #4183
[V2 cold start] Cache Expression compilation results during placeholder mode to avoid recompiles during specialization mode #4184

For a simple hello world C# function, we see cold start of ~2 seconds and once issue #2 is fixed that should be improved by another 30-40%.

ChristianWeyer · 2019-08-15T13:33:36Z

@safihamid the second issue you mention has been closed by @fabiocav - why exactly? And does this mean that there are/will not be further cold start improvements? 🤔

safihamid · 2019-08-15T17:14:06Z

@ChristianWeyer both issues mentioned above have already been addressed. For the issue which is closed we ended up doing an alternative approach.

And we are constantly working on improving cold starts. It is one of the most important tasks of few of us here at msft :-) there are some major improvements coming in the next couple of months :-)

ChristianWeyer · 2019-08-16T07:04:17Z

Glad to hear! :-)

petro2050 · 2020-04-18T14:11:34Z

@safihamid @fabiocav @jeffhollan According to this article (https://mikhail.io/2019/03/reducing-azure-functions-cold-start-time/), running from a zip file actually increases cold start times. Can you comment on that?

I have C# functions as well that are deployed as a package, and my cold starts can be as long as 12-15 seconds. This is unacceptable for a production app. What is the future of consumption plans? If I purchase a premium plan, why should I choose Functions over App Service Plan?

safihamid · 2020-04-18T15:48:27Z

@petro2050 running from zip should not increase your cold start. Make sure you are deploying using the latest Functions SDK which actually decreases the zip size. Is it V2 or V3 app? Are you adding lots of extra dependencies? If yes make sure you publish with ReadyToRun set to true.

petro2050 · 2020-04-19T16:47:03Z

@safihamid It's V3.

<TargetFramework>netcoreapp3.1</TargetFramework>
<AzureFunctionsVersion>v3</AzureFunctionsVersion>

Do I need to update my host.json file as well?

{
"version": "2.0"
}

As for the dependencies, in bin folder, I have 133 dlls. The unzipped size for all is 29 MBs. Is this too much?
Do you have support for ReadyToRun? When I set it to true, I cannot publish the app via VS. I'm getting the following error:

Unable to optimize assemblies for performance: a valid runtime package was not found. Either set the PublishReadyToRun property to false, or use a supported runtime identifier when publishing.

#5876

Do you run any optimizations on your end with respect to assemblies? I realized out of the 29 MBs, EntityFramework takes up 8 MBs. Maybe you can GAC it on the server and avoid transferring the files? Most .NET server projects use EF nowadays (though versioning can be a problem).

safihamid · 2020-04-19T17:09:40Z

@petro2050 i answered on the other git issue you mentioned. Make sure your Microsoft.NET.Sdk.Functions SDK version in .csproj file is 3.0.5 or higher.

And then you can publish your project by passing RID to publish command:
dotnet publish your prod.csproj -r win-x86 -c release

You can add the RID like win-x86, win-x64, ... to your csproj as well.

Zip file size for your function app is large. We are releasing some major improvements for download time in the next few months but in the mean time you might want to consider using premium azure files for your file storage if zip size for your scenario continues to be large. But I am pretty sure most of your cold start time is JIT time for your external assemblies and R2R should significantly improve it.

petro2050 · 2020-04-19T17:28:10Z

I'm on SDK 3.0.3 right now and unable to upgrade due to an issue with System.IdentityModel.Tokens.Jwt.

System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.IdentityModel.Tokens, Version=6.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified.File name: 'Microsoft.IdentityModel.Tokens, Version=6.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'

Is this related to you or JWT?

I will use premium storage since I don't expect the zip size to shrink as I'm using only the most essential packages for my server infrastructure. Looking forward to the updates in the coming months. :)

safihamid · 2020-04-19T17:34:21Z

@petro2050 not sure about that issue, @fabiocav do you know why he can’t upgrade to 3.0.5, have you seen above error?
@petro2050 again I think enabling R2R should significantly improve your cold start. If it didn’t send me your app name and I will look further.

petro2050 · 2020-04-24T23:27:40Z

@fabiocav Any input with regards to the JWT issue would be appreciated.

vitalybibikov · 2020-04-26T14:07:52Z

@petro2050 It's yet another not tested release of AF with an issue in 3.0.6

To fix it, for now add in project file.

  <PropertyGroup>
    <_FunctionsSkipCleanOutput>true</_FunctionsSkipCleanOutput>
  </PropertyGroup>

Still can't deploy with the settings below:

  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <AzureFunctionsVersion>v3</AzureFunctionsVersion>
    <PublishReadyToRun>true</PublishReadyToRun>
    <RuntimeIdentifiers>win-x64</RuntimeIdentifiers>
  </PropertyGroup>

with error:

Unable to optimize assemblies for performance: a valid runtime package was not found. Either set the PublishReadyToRun property to false, or use a supported runtime identifier when publishing.

safihamid · 2020-04-27T15:09:36Z

@vitalybibikov are you trying to build from a non-windows machine? If RID is win-x86 or win-x64 then you will need to build from a Windows machine, similarly you can’t build Linux-x64 from Windows.

vitalybibikov · 2020-04-29T09:15:55Z

Hi, @safihamid
No, I'm building from Windows machine, Win10, Ver 2004, 19582.1001 if it matters

It actually works locally, so with RID I can run the function and it operates (locally)
But Publish to Azure fails, till RID + R2R are removed

safihamid · 2020-04-29T17:36:44Z

@vitalybibikov I was able to repro your issue and there is a typo in your .csproj file. when R2R is enabled you will need to use
<RuntimeIdentifier> and not <RuntimeIdentifiers>

Here is how your .csproj file should look like:

`

<TargetFramework>netcoreapp3.1</TargetFramework>
<AzureFunctionsVersion>v3</AzureFunctionsVersion>
<PublishReadyToRun>true</PublishReadyToRun>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>

<ItemGroup> <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="3.0.6" /> </ItemGroup>

Also remember Azure Functions by default are 32bit in Windows, if you are deploying win-x64 you must change the platform to 64bit here is the screenshot from Azure portal:

vitalybibikov · 2020-04-29T18:04:45Z

@safihamid Whoa, thanks, not easy to spot this one

vitalybibikov · 2020-04-30T09:54:31Z

And the reason why I'm using x64 is that x86 currently does not work.
I've tried it on a newly created VM as well as on my machine.

OS: Win10
Azure Functions Core Tools (3.0.2245 Commit hash: 1d094e2f3ef79b9a478a1621ea7ec3f93ac1910d)
Function Runtime Version: 3.0.13139.0
VS 16.5.4

How to repro:

Just create an app from template.
Set the following: RID win-x86 or win10-x86

  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <AzureFunctionsVersion>v3</AzureFunctionsVersion>
    <RuntimeIdentifier>win-x86</RuntimeIdentifier>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="3.0.6" />
  </ItemGroup>

And you will get:

If I switch it to x64, it starts.

  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <AzureFunctionsVersion>v3</AzureFunctionsVersion>
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
  </PropertyGroup>

Might it be that recently cli goes x64 by default, I haven't checked yet.

vitalybibikov · 2020-04-30T11:16:20Z

The reason is that default "Platform Target" for Azure Functions projects is now x86.
So it does not work in configuration: win-x86 + platform x86. (why?)

However, it starts in the Cofiguration of win-x86 + Any CPU
But then it fails if you have SqlClient lib installed (I guess everything with Dapper, ADO, EF Core)
with an error:

System.TypeInitializationException: The type initializer for 'Microsoft.Data.SqlClient.TdsParser' threw an exception
due to some issue with SNI deps, they have a bunch of bugs related to that in github.

So, the only possible configuration is win-x64 + target x64, Unfortunately.
Which actually performs slower during load/perf testing, than a simple configuration.

safihamid · 2020-04-30T18:37:06Z

@vitalybibikov I understand there seem to be some issues with CLI when RuntimeIdentifier is win-x86 but that's only for running locally. when deploying to Azure it should work fine for both win-x86 or win-x64. isn't that the case for you?
tracking the CLI issue here: https://github.com/Azure/azure-functions-vs-build-sdk/issues/382

vitalybibikov · 2020-05-01T09:59:31Z

Unfortunately, no.

32bit in azure + 
<RuntimeIdentifier>win-x86</RuntimeIdentifier>

In Azure:
The 'XFunction' function is in error: Microsoft.Azure.WebJobs.Host: Error indexing method 'XFunction'. Microsoft.Azure.WebJobs.Host: Cannot bind parameter 'token' to type FunctionTokenResult. Make sure the parameter Type is supported by the binding. If you're using binding extensions (e.g. Azure Storage, ServiceBus, Timers, etc.) make sure you've called the registration method for the extension(s) in your startup code (e.g. builder.AddAzureStorage(), builder.AddServiceBus(), builder.AddTimers(), etc.).

Locally:

64bit in azure + 
<RuntimeIdentifier>win-x64</RuntimeIdentifier>

Works in azure
Works locally

MikePennington · 2020-05-20T22:43:31Z

I've seen similarly horrendous startup times with http-triggered dotnet function apps (10+ seconds) and have tried everything I've found online and then some to bring it down. The best option I've found is actually to use the func azure functionapp publish command instead running dotnet publish and az functionapp deployment source config-zip yourself. I don't know what kind of magic it is doing under the hood, but my cold starts now average out to just a little under 2 seconds.

petro2050 · 2020-05-25T03:38:07Z

@safihamid

Zip file size for your function app is large. We are releasing some major improvements for download time in the next few months but in the mean time you might want to consider using premium azure files for your file storage if zip size for your scenario continues to be large. But I am pretty sure most of your cold start time is JIT time for your external assemblies and R2R should significantly improve it.

I wanted to switch to using a premium storage account, but it looks like Azure Functions only works with general-purpose accounts. How can I use premium azure files? Would appreciate your input on that as I expect to go to production this year.

https://docs.microsoft.com/en-us/azure/azure-functions/storage-considerations

safihamid · 2020-05-26T17:16:28Z

@petro2050 you can create your func app using a premium storage account then add the AzureWebJobsStorage app setting and sets its value to a general-purpose storage account. that storage account will be used for logging, ... but your content will be stored on premium storage account. Again we are significantly improving the download time from regular storage in the next few months.

safihamid · 2020-05-26T17:18:08Z

@MikePennington not sure why you see 10+ seconds of cold start, you should see the cold starts of ~1 second or so. feel free to share your app name and we can take a look.

MikePennington · 2020-06-01T21:01:24Z

Thanks @safihamid, I'd love the help! As I mentioned above, I see much better results when I deploy using the func cli, so I thought I had a solution to the issue, but now I am having difficulty using func in Azure DevOps, so I would greatly appreciate more insight here.

I have deployed the same codebase using two different methods. The infra is defined in an ARM template and is the same for both.

Using az functionapp deployment source config-zip. Cold start times between 9 - 11 seconds.
https://mpapiaz-mikepenn.azurewebsites.net/api/rop/65?siteNumber=1

Using func azure functionapp publish. Cold start times between 1 - 1.5 seconds.
https://mpapifunc-mikepenn.azurewebsites.net/api/rop/65?siteNumber=1

petro2050 · 2020-06-02T15:13:42Z

@safihamid It says premium storage accounts only support page blobs. Don't I need file shares with Azure Functions?

When I try to create a function app with premium storage, I'm getting BadRequest on Azure Portal. It's unable to resolve _accountname_.file.core.windows.net.

safihamid · 2020-06-02T18:48:12Z

@MikePennington took a look at the logs, az functionapp deployment include several other config, app settings, ... and cause the process to restart and that's why it takes longer because after restart it's not going to use our specialized process for cold start and that's by design. but it only happens the very first time after a redeploy and subsequent cold starts are fast and should all be well below 1 sec.

safihamid · 2020-06-02T18:52:02Z

@petro2050 you should be using premium azure files. not sure if portal gives you that option or not. maybe you should do ARM calls to set it up. anyhow we have major improvements being deployed in the next month or so which improves this significantly as long as you have a .zip file and use 'run from package' and will not need premium azure files.

MikePennington · 2020-06-03T21:40:42Z

@safihamid Thank you very much for the info!

I have been testing cold-start times throughout the day. The following table shows response time, in seconds, for the function app deployed via the az command and the func command.

time        az          func
5:25PM      1.3         1.2
9:10PM      0.9         1.1
-- REMOVED TIMER TRIGGED FUNCTION --
9:45AM      14.2        4.6
11:45AM     4.5         2.8
1:01PM      3.7         4.3
4:17PM      4.3         4.7

The good news is that they two apps do indeed behave similarly after the first warm-up event after deployment!

I also had a timer-triggered function in the same function app that triggered every 5 minutes. This didn't actually do anything, but I added it because in my testing I found that it helped lower cold start times. After the first two tests I removed this timer trigger and cold start times got much worse.

Based on your experience with Azure functions, are these cold-start times normally expected? Is there anything else I can do to decrease the cold-start time besides adding the timer trigger? Once they warm up these functions return in well under 100ms.

safihamid · 2020-06-03T21:58:35Z

@MikePennington it's still pretty high, should be around 1 sec and soon it should be even lower. make sure you don't have any extra logging enabled in your host.json file. also make sure you do have compiled and deployed with PublishReadyToRun set to true. feel free to email me your function app code at hamids at microsoft dot com and I will take a look.

petro2050 · 2020-06-03T22:21:01Z

@safihamid

as long as you have a .zip file and use 'run from package' and will not need premium azure files

Thanks. I will wait for the improvements then.

vitalybibikov · 2020-06-04T08:08:13Z

These are my cold starts for 1 of 4 applications:

Quite far from 1 second:

Deployed as Package.

For instance, another one is about to be OK:

Both, deployed in the same way, there is no that much difference in resulting package's size.

safihamid · 2020-06-04T16:52:12Z

@vitalybibikov so you are saying 1 out of your 4 applications has a random long cold start and the rest are well below 500 msec? Do you have any external calls in your apps that might increase your cold start? Feel free to share with me the names of your apps and I can take a look.

MikePennington · 2020-06-04T19:37:58Z

@safihamid To make sure I'm not doing anything wrong, I went into Visual Studio code and created and deployed a new http-triggered function using the Azure Functions (azuretools.vscode-azurefunctions) VS Code addon. I would assume this would give me the best case scenario for cold starts since its all sample code from Microsoft. Using this auto-generated hello world function, I get the following results:

time		seconds
9:12AM		10.6 <= Assuming this is the first-time startup penalty
10:10AM		1.4
11:07AM		1.2
2:10AM		1.4
2:32AM		2.2

I am on a mac, so using PublishReadyToRun into a windows function is not an option. The mythical sub-second cold start time seems elusive to me.

safihamid · 2020-06-04T20:16:13Z

@MikePennington yes 1.4 sec is about right and soon it will be even much lower and in the sub-second range. the 2.2 sec is most likely the azure files latency and will go away soon as well. if your project has more complex code, you will need to publish with PublishReadyToRun enabled or else you will pay the JIT cost during cold start.

vitalybibikov · 2020-06-15T13:24:49Z

@safihamid
The one that is most affected is "loyaltyprogram-dev" function app

I can see 30 seconds cold starts from time to time. As I"ve mentioned before.

vitalybibikov · 2020-07-06T12:13:25Z

Hi @safihamid,

Have you found anything specific?

jcageman · 2020-08-26T08:17:52Z

We are seeing very long startup times (30+ seconds) during scale out of our function app within an appservice plan. Any suggestions to analyse such long startup times? We noticed that it does decrease with better hardware, but we would expect 2-3 seconds at most.

a-vishar · 2020-08-26T13:46:43Z

Went through this with Azure Support recently. Even on Premium we see the 30+ second times seemingly randomly (host still available and serving traffic and no spike in calls/resource consumption)... Advised to move to dedicated, but that the "Expected" cost of up to 1.5 seconds will still be present there.

jeffhollan · 2020-08-26T16:16:00Z

@a-vishar do you have any info you can share on this one? For premium we do all you to define the pre-warmed buffer where we should be pre-emptively scaling and warming apps for you, even custom containers.

a-vishar · 2020-09-16T12:46:18Z

@jeffhollan - I have an open case with support (120061622003116). If you require specific information to help you debug, please do reach out.

judyanndixon · 2020-10-09T18:43:23Z

I've seen similarly horrendous startup times with http-triggered dotnet function apps (10+ seconds) and have tried everything I've found online and then some to bring it down. The best option I've found is actually to use the func azure functionapp publish command instead running dotnet publish and az functionapp deployment source config-zip yourself. I don't know what kind of magic it is doing under the hood, but my cold starts now average out to just a little under 2 seconds.

I also got better cold starts using func azure functionapp publish with a simple functionapp that just does a redirect. I was seeing around 15 seconds after a deployment using Visual Studio, with the func azure functionapp publish it was down around 2. Wonder what the one tool is doing that the other needs to be doing?????

MikePennington · 2020-10-09T20:02:02Z

@judyanndixon I went pretty deep down this rabbit hole a few months back. Here's what I learned:

There are two different levels of cold start times. "First time ever called" cold start and "normal" cold-start. Best I can tell is that the only difference is that func azure functionapp publish pre-warms the function where az functionapp deployment does not. This removes the penalty of the "first time ever" penalty. Once they have both sit for a while I've seen similar cold start times between the two deployment methods.

The best way I've found to reduce unacceptable cold start times in Azure functions is to add this:

        [FunctionName("keepalive")]
        public void KeepAlive([TimerTrigger("0 */10 * * * *")]TimerInfo myTimer)
        {
            // Do nothing, this is used to improve cold-start time
        }

judyanndixon · 2020-10-10T00:06:24Z

Good to know. Thanks!

…

Sent from my iPhone

On Oct 9, 2020, at 4:02 PM, Mike Pennington ***@***.***> wrote: @judyanndixon I went pretty deep down this rabbit hole a few months back. Here's what I learned: There are two different levels of cold start times. "First time ever called" cold start and "normal" cold-start. Best I can tell is that the only difference is that func azure functionapp publish pre-warms the function where az functionapp deployment does not. This removes the penalty of the "first time ever" penalty. Once they have both sit for a while I've seen similar cold start times between the two deployment methods. The best way I've found to reduce unacceptable cold start times in Azure functions is to add this: [FunctionName("keepalive")] public void KeepAlive([TimerTrigger("0 */10 * * * *")]TimerInfo myTimer) { // Do nothing, this is used to improve cold-start time } — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

antonysmith-mando · 2023-09-20T16:48:45Z

@safihamid is the above suggestion - re: using a TimerTrigger to keep a Consumption plan Function App warm - a valid one?

I have added a TimerTrigger to my Function App for this purpose. I can see that the function executions are logged every 5 minutes, but that the AppDomains remains at 0:

Function executions, steady line at 1 execution through the night:

However, Total App Domains is 0 during this time:

This results in a cold start being experienced as part of the first request of the day.

Sorry to drag up a (very!) old thread, but would be very interested to know if this is expected behaviour, or if there's something wrong with my setup.

Thanks!

safihamid · 2023-09-20T17:04:17Z

That is one way but there are many other ways to make sure you are getting best cold start. check Risk Alerts in Azure portal for your app and see if there are any suggestions to improve cold start of your app. Are you deploying with Ready2Run? Are you using WEBSITE_RUN_FROM_PACKAGE=1 if running on Windows? ...

antonysmith-mando · 2023-09-20T17:11:33Z

Thanks for getting back to me.

I am running from a package, not sure about R2R, would have to check.

However, the idea of me using a TimerTrigger is to keep the Function App warm and avoid the cold start, rather than improve it. Is that not achievable?

For instance, see the log extract below. You can see that my timer function runs at 09:45:00 and my HTTP function is run at 09:45:16 and 09:48:40. All 3 invocations are are on the same instance. My intention behind running the timer trigger is for no cold start to be observed on the HTTP function in this scenario, but the first call to it is ~4x slower than the first. Is this indicative of cold start? And can this be avoided in the way I am trying to avoid it?

Many thanks for your support.

safihamid · 2023-09-20T17:57:20Z

The fact that your timer trigger and http Function landed on same instance means the timer trigger did the job of cold starting your function app for the Azure Functions platform. Meaning your instance was assigned, your zip package was downloaded and extracted, the env variables and app settings for your app where applied, ...

The fact that your 1st http trigger still took longer means your timer trigger didn't exercise much of your own code needed for your http trigger execution.

Is this a .NET app? if yes, most likely time was spent JITting your code. did you need to setup some outbound connections? the more of your code you exercise in your timer trigger the less time spent on your very 1st http trigger.

The concept is very similar to Azure Function warmup triggers documented here: https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-warmup?tabs=in-process&pivots=programming-language-csharp

But keep in mind warmup triggers are only supported for Premium and App Service plans and are not supported for consumption. but you can implement same logic for your custom timer trigger code.

antonysmith-mando · 2023-09-20T22:47:08Z

@safihamid thanks very much for your detailed response.

I've had a look back at the cold start times before I added the TimerTrigger and these look to generally be in excess of 2s - double what they are now.

If I understand what you're saying correctly, that's because:

The TimerTrigger is now ensuring that the instance is warm, and the environment prepared
But there's still work to do to warm up the specific code in my HTTP trigger that hasn't been warmed by what the TimerTrigger does (which is nothing more than log a message that the function was executed)

The former is why I'm seeing a ~50% improvement, but the latter is why I'm still seeing some slowness on the first request to the HTTP trigger.

The HTTP function in question is made up of primarily C# calculation logic. The only dependency is on Azure Blob Storage for config files - there are no other outbound calls. Am I right in thinking that the platform should be keeping that connection warm for me? In which case the time being taken on first invocation is purely for JITing the code and I think my next approach would be to warm up the HTTP trigger function itself.

Thanks for your help!

safihamid · 2023-09-20T23:39:29Z

yep, maybe easiest is to fake call all the logic that you have in your http trigger function into your Time Trigger so all code paths are JITted and warmed up? And make sure you deploy with Ready2Run to minimize overall JIT time.
Do you call into Azure blob storage on your http trigger? if yes that code needs to be warmed up as well.

antonysmith-mando · 2023-09-21T08:23:33Z

I think it may actually be easier for me to just call the real HTTP function. Its execution is reliant on all of the config files from Blob Storage being present and it will fail fast if they're not. So I'd need to also provide all of those to my TimerTrigger in order to warm up all of the code paths, in which case I may as well just run the real thing (otherwise I'd be basically duplicating this specific HTTP function within the TimerTrigger function, which wasn't my intention, it was to have a generic 'keep-alive' function, which I now understand isn't completely valid because the function-specific code still needs to be warmed).

The function is executed on submission of a web form, so I should be able to eagerly call the HTTP function with a dummy request on load of the form, meaning that warm up has occurred prior to submission of the form and the 'real' invocation.

As part of this work, I will ensure I've got R2R set up and will enjoy the additional benefits that brings for cold start times. Thanks again for all of your help.

safihamid · 2023-09-21T15:03:25Z

Yep, sounds like a good plan. We in Azure Functions team are constantly working on improving Functions cold start specially what is related to the cold start of the platform itself. In fact in the past few months, we improved the platform cold start by ~40% in most regions. the deployment is still ongoing.

But if cold start is related to the specific Function code itself, you need to make sure zip package is minimized by removing all unnecessary content, the code is compiled with Ready2Run or AOT compiled and follow all the guidance of cold start Risk Alerts if any that we show on the portal under Diagnose & Solve problems. And don't forget about warmup triggers if running in premium or App Service plans.

Cold start time took more more than 10 secs with C# compiled + "Run from package" for Azure function v2 #3965

Cold start time took more more than 10 secs with C# compiled + "Run from package" for Azure function v2 #3965

Comments

RudyLu commented Jan 16, 2019

Investigative information

Repro steps

Expected behavior

Actual behavior

Known workarounds

Related information

safihamid commented Feb 28, 2019

RudyLu commented Mar 10, 2019

safihamid commented Mar 11, 2019

safihamid commented Mar 11, 2019 • edited Loading

ChristianWeyer commented Aug 15, 2019

safihamid commented Aug 15, 2019

ChristianWeyer commented Aug 16, 2019

petro2050 commented Apr 18, 2020

safihamid commented Apr 18, 2020

petro2050 commented Apr 19, 2020 • edited Loading

safihamid commented Apr 19, 2020 • edited Loading

petro2050 commented Apr 19, 2020

safihamid commented Apr 19, 2020

petro2050 commented Apr 24, 2020

vitalybibikov commented Apr 26, 2020

safihamid commented Apr 27, 2020

vitalybibikov commented Apr 29, 2020 • edited Loading

safihamid commented Apr 29, 2020 • edited Loading

vitalybibikov commented Apr 29, 2020

vitalybibikov commented Apr 30, 2020 • edited Loading

vitalybibikov commented Apr 30, 2020 • edited Loading

safihamid commented Apr 30, 2020 • edited Loading

vitalybibikov commented May 1, 2020 • edited Loading

MikePennington commented May 20, 2020

petro2050 commented May 25, 2020 • edited Loading

safihamid commented May 26, 2020

safihamid commented May 26, 2020

MikePennington commented Jun 1, 2020

petro2050 commented Jun 2, 2020

safihamid commented Jun 2, 2020

safihamid commented Jun 2, 2020

MikePennington commented Jun 3, 2020

safihamid commented Jun 3, 2020

petro2050 commented Jun 3, 2020

vitalybibikov commented Jun 4, 2020 • edited Loading

safihamid commented Jun 4, 2020

MikePennington commented Jun 4, 2020 • edited Loading

safihamid commented Jun 4, 2020

vitalybibikov commented Jun 15, 2020 • edited Loading

vitalybibikov commented Jul 6, 2020

jcageman commented Aug 26, 2020

a-vishar commented Aug 26, 2020

jeffhollan commented Aug 26, 2020

a-vishar commented Sep 16, 2020

judyanndixon commented Oct 9, 2020

MikePennington commented Oct 9, 2020

judyanndixon commented Oct 10, 2020 via email

antonysmith-mando commented Sep 20, 2023

safihamid commented Sep 20, 2023

antonysmith-mando commented Sep 20, 2023 • edited Loading

safihamid commented Sep 20, 2023

antonysmith-mando commented Sep 20, 2023

safihamid commented Sep 20, 2023

antonysmith-mando commented Sep 21, 2023 • edited Loading

safihamid commented Sep 21, 2023

safihamid commented Mar 11, 2019 •

edited

Loading

petro2050 commented Apr 19, 2020 •

edited

Loading

safihamid commented Apr 19, 2020 •

edited

Loading

vitalybibikov commented Apr 29, 2020 •

edited

Loading

safihamid commented Apr 29, 2020 •

edited

Loading

vitalybibikov commented Apr 30, 2020 •

edited

Loading

vitalybibikov commented Apr 30, 2020 •

edited

Loading

safihamid commented Apr 30, 2020 •

edited

Loading

vitalybibikov commented May 1, 2020 •

edited

Loading

petro2050 commented May 25, 2020 •

edited

Loading

vitalybibikov commented Jun 4, 2020 •

edited

Loading

MikePennington commented Jun 4, 2020 •

edited

Loading

vitalybibikov commented Jun 15, 2020 •

edited

Loading

antonysmith-mando commented Sep 20, 2023 •

edited

Loading

antonysmith-mando commented Sep 21, 2023 •

edited

Loading