Logic Apps connector performance (2/3) – The ugly

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:

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.

Perf2

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

Perf3

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

Perf4

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.

Perf5

Fortunately, the monitoring view behaves like expected:

Perf6

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

About me

Hi! I’m Toon Vanhoutte, a hands-on Azure architect – based in Belgium – with a big passion for teaching and helping people out. I’m happy to assist you during your Azure journey with high-quality advisory and I would love to teach you Azure’s possibilities via my tailored training courses.

Subscribe to the blog