3
votes

So, I'm analyzing whether using Functions to consume Service bus messages from a topic is viable.

The Service Bus pricing plan we chose has a limit on the number of 'Brokered connections' (max 1000) per month.

My understanding is that in the typical usage scenario the consumer/listener/subscriber connects to a topic and stays connected persistently, receiving multiple messages during a long period of time (a day, even a week) without breaking the connection, and that this is counted as 1 'brokered connection'. In the end you can receive thousands of messages on a single brokered connection.

How does this work with an Azure function binding? From what I read in the documentation, a function can be idle (ie not running), so it wouldnt be able to maintain this persistent connection.

Is there a separate component for Functions that keeps this connection alive listening for incoming messages? Or are we going to get billed for a new brokered connection each time the function goes idle and then restarts?

I'm including a screenshot of the current plan features: https://azure.microsoft.com/en-us/pricing/details/service-bus/

current plan features

Later in the same link:

Brokered connections overage


edit

From Docs:

Service Bus charges for the peak number of concurrent brokered connections that exceed the included quantity (1,000 in the Standard tier). Peaks are measured on an hourly basis, prorated by dividing by 744 hours in a month, and added up over the monthly billing period. The included quantity (1,000 brokered connections per month) is applied at the end of the billing period against the sum of the prorated hourly peaks.

They specifically mention "1,000 brokered connections per month" in the last sentence.

This is an example:

Each of 10,000 devices connects via a single AMQP connection, and receives commands from a Service Bus topic. The devices send telemetry events to an Event Hub. If all devices connect for 12 hours each day, the following connection charges apply (in addition to any other Service Bus topic charges): 10,000 connections * 12 hours * 31 days / 744 = 5,000 brokered connections. After the monthly allowance of 1,000 brokered connections, you would be charged for 4,000 brokered connections, at the rate of $0.03 per brokered connection, for a total of $120.

So I guess all of this is for 10.000 subscribers connecting to the topic at the same time during 12hs, if they connected for 24hs each day then 9,000 brokered connections would be billed (10,000 minus the included 1,000)?

In any case, I'm also trying to validate whether persistent connections are possible with functions (I'm told they are with webjobs).

1
have you found answer to this ? I too am worried about brokered connection and nobody seems to understand the cost in azure function triggerNick Chan Abdullah

1 Answers

2
votes

Azure Functions has a separate component known as the ScaleController that monitors your Service Bus for events 24/7.

Since the underlying SB message receiver in Functions is implemented in WebJobs, there will be a single connection that can retrieve multiple messages throughout the lifetime of the Function instance, although due of its current limitation, it is passing along those messages one at a time to your Function code for processing.

You are only charged when your Function code actually runs. Here's a link that gives you an overview of the ScaleController:https://docs.microsoft.com/en-us/azure/azure-functions/functions-scale#runtime-scaling

If you are anticipating relatively high load, have you considered using Event Hub instead of Service Bus? ServiceBus-Triggers in Azure Functions currently can only process one message at a time, which is not optimal for high load scenarios. Here's a GitHub issue that is opened to track this feature request: https://github.com/Azure/azure-webjobs-sdk/issues/1024

EventHub-Triggers can process messages in batches and that should give your more bang for the buck per Function execution. See https://docs.microsoft.com/en-us/azure/azure-functions/functions-bindings-event-hubs