We are about to develop a microservice architecture with azure functions inside azure. We thought about using interservice communication with durable functions. On app site we want to use an async pub/sub pattern to publish request/commands through a single function gateway. This command will be forwarded to other durable functions and processed there. The response to app will be responded asynchronously via signalR.

All data that need to be processed inside not stateless services will be send via EventGrid/EventHub to the specific cloud services via streaming.

The performance of the durable functions for a roundtrip (App-Functions-App) is about 300 ms. Does anyone has some ideas how to improve the performance?

Architecture Overview

  • 2
    It seems to me that almost every design choice here adds latency. How married are you to this design? – JimmyJames Mar 15 at 19:51
  • Not very much, we still could change everything, what exactly would you suggest, or where do you see the problems? – Andre Laskawy Mar 15 at 20:01
  • 1
    Asynchronous designs tend to be more appropriate for optimizing throughput and/or handling handling uneven demand with a fixed amount of resources. What is your performance goal here? Are your trying to improve throughput, latency, or something else like cost per transaction? – JimmyJames Mar 15 at 20:20
  • Well the typical answer: all of it! - Latency should be acceptable (a request made by a user should be answered directly). - The idea is to have high throughput caused by huge amount of users. Stream analysis, calculations made on user input, etc. - Cost should be low of course, that is one of the reason we choose azure functions. – Andre Laskawy Mar 15 at 20:31
  • These tend to be tradeoffs but I'll ask a couple more questions. I'm not very familiar with durable functions but, as I understand it, the main cost benefit of serverless functions is that you don't pay for them when they are not being used. The tradeoff for that has been that there is some latency to bring them up when requests are made. So are you expecting these to be idle and why did you decide on durable functions over stateless functions? Is it for fan-out, fan-in? – JimmyJames Mar 15 at 20:57

Performance can better be discussed as perceived performance, rather than the time it takes to make a round-trip. Please search for ways to improve a web page's perceived performance, e.g. "Optimistic UI".

If you place user's request as a message in a queue instead of processing it immediately (maybe that's what you have in mind already), you might be able to assume that it will be processed succesfully and upon placing of the message in the queue, you could notify the user of success. Only if the processing of the message is not succesful, which should occur rarely, you can then notify the user that it was failed. Even this can be questioned in which cases it is necessary to notify after unsuccesful processing.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.