28

The scaling documentation for Azure Functions is a bit light on details for how Azure Functions decide when to add more instances of an app.

Say for example I have a function that is triggered by a Github webhook. 10,000 people simultaneously commit to the Github repo (with no merge conflicts ;) ), and Github calls my function 10,000 times in a very short period of time.

What can I expect to happen? Specifically,

  1. Will Azure Functions throttle the webhook calls? i.e., will Azure Functions reject certain function calls if my function app is under high load?
  2. Does Azure Functions queue the requests somehow? If so, where/how?
  3. How many instances of my function app will Azure Functions create in this scenario? One for each request (i.e., 10,000), and each will run in parallel?
  4. If my app function was scaled down to zero instances, because there was no load on it, could I expect to see some "warm-up time" before the first function is executed? Roughly how long?
dmulter
  • 2,608
  • 3
  • 15
  • 24
Adrian Hofman
  • 1,421
  • 1
  • 11
  • 24

2 Answers2

25
  1. Azure Functions won't reject a webhook call, but in the case of sudden, extreme load, some requests may timeout. For web apis, please include retry on the client, as a best practice.
  2. They aren't queued in any persistent place. They are (implementation detail) managed by IIS.
  3. (Implementation detail) Number of instances isn't a hard set thing. We have certain, unpublished protections in place, but we're designed to scale quite far. Your requests will be handled by multiple instances.
  4. Yes. Right now, it's pretty hefty (seconds), but we'll be working to improve it. For perf sensitive situations, a canary or a timer trigger to keep it awake is recommended.

I'm from the Azure Functions team. The things I marked as implementation details aren't promises and will likely also change as we evolve our service; just an attempt at transparency.

Chris Anderson
  • 8,305
  • 2
  • 29
  • 37
  • Could you expand on the timer trigger solution ? Can I have another timer triggered function on the Function App, and depend on it to keep the HTTP triggered functions 'warm' ? – Shrulik Apr 24 '17 at 11:12
  • 1
    If you have another Function like a timer trigger on the same Function App, it will keep a warm instance around for another execution, today, yes. – Chris Anderson Apr 25 '17 at 06:39
  • Thanks. The "today" is a bit worrying, but I appreciate the honesty. – Shrulik Apr 25 '17 at 08:34
  • That was intentional. We don't promise we won't change the behavior in the future, but we have no current plans to change it and no pressures (such as lack of capacity) to change it. We'd change it if we wanted to increase the utilization of our resources, but not before we made cold start a non-issue for folks. – Chris Anderson Apr 25 '17 at 22:54
  • After some experimenting I think this is not true, or no longer true for precompiled azure functions. I added a timer function, which runs every minute, and it is easy to confirm it really does that as all it does is write a Trace, and yet after about 10 minutes of inactivity, I pay a warm up fee of about 5-10 seconds. – Shrulik Apr 30 '17 at 13:41
  • That shouldn't be the case. I'd create a new Question with an example time period and you can give us an invocation id + region, and we can investigate the sleeping activity. – Chris Anderson May 01 '17 at 18:30
  • @ChrisAnderson-MSFT: Can I use Azure Functions to read all blobs from a given (live) container (say containing Azure Webapp logs) and send to another place? Since a blob can be appended multiple times, data passed to a Function via Blob triggers actually overlap. In theory, I can do bookeeping on the number of read bytes for each blob in a separate place (like a Table storage) but synchronization then is a big issue as different triggers on the same blob will be handled by different functions. – David Ha Jul 10 '17 at 08:08
6
  1. tested today. it took more than seconds :(
ACTUAL PERFORMANCE
--------------
ClientConnected:  13:58:41.589

ClientBeginRequest:   13:58:41.592

GotRequestHeaders:    13:58:41.592

ClientDoneRequest:    13:58:41.592

Determine Gateway:    0ms

DNS Lookup:       65ms

TCP/IP Connect:   40ms

HTTPS Handshake:  114ms

ServerConnected:  13:58:41.703

FiddlerBeginRequest:  13:58:41.816

ServerGotRequest: 13:58:41.817

ServerBeginResponse:  14:00:36.790

GotResponseHeaders:   14:00:36.790

ServerDoneResponse:   14:00:36.790

ClientBeginResponse:  14:00:36.790

ClientDoneResponse:   14:00:36.790


Overall Elapsed:  **0:01:55.198**
NoWhereToBeSeen
  • 1,404
  • 1
  • 13
  • 22