locked
NodeJs concurrent requests? RRS feed

  • Question

  • The documentation I've seen so far has been a little murky on this point and some clarification would be appreciated.

    I've seen written that 1)  Azure functions can run more than one request concurrently through multi-threading and also that 2) instances of functions can scale up to 10 instances.  

    Now NodeJs isn't multi-threaded but it is non-blocking.  

    I have in mind an I/O intensive use-case where I will receive an http request, do a little bit of logic and make an async http request off to another service.  So once we have reached the async request, NodeJs should be available to begin processing another request (i.e. non-blocking).  The model in my mind for this is express.js, and for what I'm looking at I would expect this to be able to scale to 1000s of concurrent requests for a single instance.  10 instances would then be able to handle ~10x that amount.  Am I right in how I'm thinking about this?  Is a single instance something like an express.js server which can handle more than one request as a time as long as we don't block (which isn't the same as multi-threaded)?


    Thursday, June 23, 2016 8:09 PM

Answers

  • Yes, you are correct. You should be able to achieve high concurrency in such scenario on a small number of instances.

    Though one key thing to note is that the billing (once it becomes enabled) is based on the running time of each individual Function invocation, regardless of how many instances are used.

    Does that make sense?

    Thursday, June 23, 2016 9:10 PM

All replies

  • Yes, you are correct. You should be able to achieve high concurrency in such scenario on a small number of instances.

    Though one key thing to note is that the billing (once it becomes enabled) is based on the running time of each individual Function invocation, regardless of how many instances are used.

    Does that make sense?

    Thursday, June 23, 2016 9:10 PM
  • Thanks for responding.

    Yes, that makes sense and was what I expected.  Thanks for confirming as this bolsters my confidence in this offering.  

    Btw, I'm really glad you all rolled out this technology since I've had my eye on aws lambda ever since it came out.  I had seen too many red flags around it's usability and deployment stories, though, to jump right in.  So I had been looking for an alternative by a major player.  I've read through quite a bit of the documentation and while I have yet to actually try it, it looks like you all have nailed it.


    Friday, June 24, 2016 1:06 PM
  • Thanks for the feedback Brandon!

    David

    Friday, June 24, 2016 2:20 PM