1

I'm currently testing a very simple Logic App, which is triggered when a message is received in a topic subscription (auto-complete), and sends the content as an HTTP request to our server. It was able to handle a small volume, about 20 messages per second, but I increased the amount of traffic being diverted to it to 200 messages per second, and now the messages are slowly backing up on the subscription.

Why is my Logic App not scaling to handle the load? Can Logic Apps actually scale out the same way that Functions and Web Apps do?

Andrew Williamson
  • 8,299
  • 3
  • 34
  • 62
  • have you seen this post https://stackoverflow.com/questions/49653764/logic-app-and-service-bus-queue-not-scaling-logic-app-run-instances-properly ? it seems to be related – Thomas May 11 '18 at 07:27
  • Ok, I've read through that question, all the comments, and all the questions that are linked to in the comments, and have not found an answer yet. It is a very similar question, the only practical difference being that they are using sessions and I am not. – Andrew Williamson May 11 '18 at 09:42
  • I dont think session is the problem. My guess is that you can't configured the maxconcurrentcall so it wont scale. A solution could be to use an azure function with a servicebus trigger that will just call an http triggered logic app with the payload of the message – Thomas May 11 '18 at 09:51
  • We currently have our live traffic going through a Function, set up so on failure it puts the message on a queue with a delayed visibility, because there is no built-in retry logic like we have in the Logic App. This is able to handle our throughput, but it would be nice to use a Logic App because it handles the retries automatically. I just don't understand why the Logic App isn't scaling the same way. – Andrew Williamson May 11 '18 at 10:11
  • What do you mean by `there is no built-in retry logic`, if a exception is thrown by your function, your message will be abandoned and resend based on the max delivery count ? – Thomas May 11 '18 at 10:15
  • Yes, sorry I mean there is no retry policy. If my endpoint is down, the message will fail, and then it will be retried again immediately, and fail again, and ultimately it will go to the dead letter queue within seconds. I'd like it to retry after 15 seconds, then 30 minutes, then 1 hour, then 2 hours, etc. This can be specified with an exponential retry policy in a Logic App. – Andrew Williamson May 11 '18 at 10:18
  • I would be careful about using logic app for servicebus trigger. you will be charged for every polling even if there is no message in your queue. In your case I would fallback to a webjob. If you already have an existing webapp this wont cost anything. – Thomas May 11 '18 at 10:26
  • There are some things you want to check: 1) How often are you polling from Service Bus? I think every 30 seconds would be sufficient for the long poll to be almost real-time. 2) Are you using the OptimizedForHighThroughput option? (https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-limits-and-config#throughput-limits). 3) Are you leveraging queue partitioning? (https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-partitioning) It really depends on your use case, but if you want to process 200 messages per second, most probably Logic Apps will cost you more. HTH – Paco de la Cruz May 16 '18 at 02:22
  • Polling every 10 seconds, and partitioning is enabled. I've just enabled the HighThroughput option now, but it does not appear to have made a difference. – Andrew Williamson May 16 '18 at 02:56

0 Answers0