One of Logic Apps biggest selling points is the fact that the runtime is serverless, which results in a very scalable integration platform.  I’ve always been amazed by the elasticity characteristics of the Logic App engine, however there’s a huge limitation on the scalability of the out-of-the-box connectors.  On many projects, we’ve suffered from this limited connector capacity.  This blog post series walks you through the limitations (The bad!), Microsoft’s advised workarounds (The ugly!) and an approach that works great for some connectors (The good!).

This blog series consists of:

• Logic Apps connector performance (1/3) – The bad!
• Logic Apps connector performance (2/3) – The ugly!
• Logic Apps connector performance (3/3) – The good!

Let’s have a look at the workarounds that Microsoft proposes, to overcome the throttling limits of the Logic Apps connectors.

Use an API connection per action

The throttling limits are applicable per API connection.  An API connection contains the connectivity details to connect to a specific resource, application or system.  Originally, the concept of an API connection was introduced to reuse these connectivity details across actions and across Logic Apps.

When considering performance, it’ss advised to create a separate API connection for every action that you create.  This approach introduces extra developer overhead to configure this and to roll this out via CI/CD.

In some cases, this setup might solve your performance issues.  If not, you have to consider the next workaround.

Load balance between multiple API connections

If one action is still limited by the throughput of one API connection, you have to consider load balancing between multiple API connections.  These are the steps to make this happen:

• Create X API connections, preferably in an automated way
• Declare all the API connections in the code view of your Logic Apps

• Update the action, to randomly pick one of the X API connections via this expression:@parameters(‘$connections’)[concat(‘azureblob_’, rand(1,5))][‘connectionId’]

This approach works fine under a high load, but it comes with the big limitation that the designer view is completely messed-up.  This means you can only configure the action via the code view, which doesn’t seem to be stable too with this configuration.

Fortunately, the monitoring view behaves like expected:

Conclusion

A lot of extra overhead and usability drawbacks, but these workarounds do the job.  Would be great if Microsoft can fix the designer issue.  One question that always pops-up: if the product team suggests such dirty workarounds, why don’t they just increase the throttling limits?  In the final blog post of this series, we’ll look at another way to bypass the throttling limits.

Happy learning!
Toon