Are there benefits to an async function?

Question

Azure functions allows me to write C#/F# (and more) functions which are executed given certain conditions. These functions can be async (by returning a Task).

The cool thing about azure functions is that they automatically scale up depending on load. One of the cool things about the async/await pattern on a "classic" server, is that you can better utilize the cores so you can handle more requests.

Since azure functions automagically scales, are there any benefits for me to write async functions?

Gunsmith

Your question is devoid of detail. Azure's "cloud scaling" has absolutely nothing to do with C#'s async functionality. – Boorman

Azure functions runs arbitrary C#/F# functions, these functions can be async or sync. Is this option only available so that I can use await in the "top-level" function, or are there other benefits? – Gunsmith

Answer 1

You'd use async in Azure Functions for the same reasons you would in any other application. For operations that block on potentially long running external I/O, it'll be a much more efficient use of resources. Azure Functions fully supports async in the runtime core, so when used correctly, it will allow for more parallelism and better throughput on a single Function App since threads aren't blocked waiting for I/O and can be used to process more requests/triggers.

If your Function App is running on a Classic SKU, then you're paying for an Always On instance, so it's clear you want to use resources as efficiently as possible.

When running in the Dynamic SKU, I think your question was that if we'll just scale out your functions as needed, then who cares if they're using resources efficiently? I'd still say that it is best for you to code your functions so they run as efficiently as possible. That way we're only scaling you out when truly needed, and minimizing any cold start times for new instances as we spin them up.

Adrieneadrienne

Answer 2

You still benefit when you use async with Azure Functions on the dynamic plan. This is because your app is consuming fewer resources (threads in particular), making it more efficient and therefore less expensive. Some examples come to mind:

• Context switching: When running highly concurrent workloads, you will end up with a larger number of threads assigned to your function app instance. This larger number of threads will result in expensive context switches, which increase the latency of function execution and therefore may increase your bill.
• Thread Pool Growth: If you have a lot of threads and need to add more, this can add additional latency to your function execution due to how the CLR throttles the growth of the thread pool. Jon Cole has a nice description of this here:

Once the number of existing (busy) threads hits the "minimum" number of threads, the ThreadPool will throttle the rate at which is injects new threads to one thread per 500 milliseconds. This means that if your system gets a burst of work needing an IOCP thread, it will process that work very quickly. However, if the burst of work is more than the configured "Minimum" setting, there will be some delay in processing some of the work as the ThreadPool waits for one of two things to happen 1. An existing thread becomes free to process the work 2. No existing thread becomes free for 500ms, so a new thread is created.

• Memory Usage: More threads means higher memory usage. Today you pay a fixed amount for the upper-limit of memory usage, but if this changes in the future to be based on actual consumed memory, then you will be paying a larger amount of money for this unnecessary memory overhead.

If it's not a lot of work, I highly recommend taking advantage of async patterns in your functions. Beyond just the reasons mentioned above, it's best not to make too many assumptions about the capacity of the platform or the efficiency of the dynamic scale logic since inaccurate assumptions could end up costing you more money. :)

Pasteurism