Azure Function – take it to the limit, scale it up

Azure Functions are really cool #AzureFunction.  I wrote numerous articles about Azure Functions here, check them out.  As you know there are 2 kinds of Azure Functions:

  • Consumption – do not have to worry about resource management
  • App Service Plan – run your functions just like other Azure App Services

Each have a different set of rules and features which you can read about here.  I write this article specifically from the App Service Plan (ASP) perspective based on an experience I had working a performance issue, see Figure 1.  When you select to run your Azure Function on an ASP you get to choose the size of the instance it runs on.  By size I mean something like 1xCPU/1.5GB, 2xCPU/3.5GB or 4xCPU/7GB.  This is in contract to an Azure Function running via the consumption plan where you do not need to manage that.


Figure 1, creating an Azure Function on an App Service Plan

The experience I had was that the Azure Function was throwing some unexpected errors and timing out.  After some analysis I realized that I was running a pretty resource intensive Function on a 1xCPU virtual machine (VM).  Looking at the CPU consumption I saw it was hitting 100%.

NOTE:  It is possible to run App Services and Azure Functions on the same ASP.  All of those App Services, Azure Functions and the OS will compete for the same resources allocated to the ASP.

To resolve the issue, I scaled my ASP to an S3 and the unexpected behaviors and exception stopped happening because there was enough CPU and memory for my function to process and complete.

To scale your Azure Function up or down, access the Azure Function and click on the Platform features link, as shown in Figure 2.  Then click on App Service Plan.


Figure 2, scaling an Azure Function hosted on an App Service Plan

When the ASP blade opens, select the Scale up link and then scale to the size in which your function requires to run in.  See Figure 3.


Figure 3, scaling an Azure Function hosted on an App Service Plan

Save the change and good things will happen.

Comments (4)

  1. Chris Surfleet says:

    Hi Ben

    Why do you not use the consumption plan for this stuff? I’ve never seen a good argument for ASP when hosted in azure itself

    1. Hi Chris, mostly because I do not have an application/product/program with enough volume or traffic to trigger such scaling to an extent where I can deeply learn its behavior and see it in real usage. Once I get more engagement in that I will write more about it. The consumption plan is certianlly awesome.

  2. SteveC says:


    have you seen any issues where a function running in Consumption plan gets “bombed” by too many requests?

    We’ve got a simple HTTP request/response function, that looked fine when we doing development, posting to it from Postman and getting approx. 200 ms response time … great

    But when we tried simple load tests and it all goes to pot … response times rock and/or we get loads of 500 errors
    Then wait a minute or two, back in Postman and response it back down to 200 ms range


    1. @SteveC, bursting a large number of parallel simultaneous requests onto any compute platform (cloud or on-premise) is not a scenario which will likely render desired results. Recommend that you do load testing with a small load initially, then gradually increase the number of virtual users overtime, I have assumed you are bursting, perhaps wrongly…? Service Bus or Storage Queues can handle bursts somewhat better because of the current intellectual property scale logic. This will certainly improve over time. Also, it for sure depends on what the Azure Function is doing, there are limits on how many items that can be processed at once. Check out these discussions: and

Skip to main content