0

We are a skills based development company that creates competitions . The players of this competition can upload photos and rank each other photos to earn points . One of the key requirements of this is to update the competition leader board regularly to keep the players interested. We are looking for a fan-out and fan in architecture to implement the leader board. A typical work flow is attached

enter image description here

From our analysis Durable functions seems to an best option.

However we have the following constraints

  1. Each competition has about 500 players
  2. A player will be ranking up to 500 photos

I have been trying to read through documentation. However could not find documentation on the scalability of this approach using Durable functions. Any comments or insights is highly appreciated

Sabarish Sathasivan
  • 1,196
  • 2
  • 19
  • 42

1 Answers1

1

You can find the performance targets for Durable Functions here: https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-perf-and-scale#performance-targets

Parallel activity execution (fan-out) 100 activities per second, per instance

Parallel response processing (fan-in) 150 responses per second, per instance

If you run on an Azure Functions Consumption plan, the scale controller there will scale up to more instances as more messages appear in the work item queue. This is the queue used to start activities (which you would use to calculate a single player's score.

You can also improve fan-in performance by doing what the say in the docs:

Unlike fan-out, fan-in operations are limited to a single VM. If your application uses the fan-out, fan-in pattern and you are concerned about fan-in performance, consider sub-dividing the activity function fan-out across multiple sub-orchestrations.

So you'd have:

  • Main orchestrator
    • Batch 0 sub-orchestrator
      • Activity for user 0 in batch 0
      • Activity for user 1 in batch 0
      • ...
    • Batch 1 sub-orchestrator
      • Activity for user 0 in batch 1
      • Activity for user 1 in batch 1
      • ...
    • ...

The reason this kind of sub-orchestrator batching makes it faster is because your orchestrator history table gets more and more rows as the activities complete. It has to load these every time there is a result. So by limiting the ceiling for those rows you get maximal performance.

TL;DR: I think the fan-out will scale well, but you may want to do sub-orchestrator batching to improve fan-in performance.

juunas
  • 54,244
  • 13
  • 113
  • 149