CODEWITHSUNDEEP
azureservicebusazure-servicebus-queues
Yuriy Gavrishov
Yuriy Gavrishov

Reputation: 5021

Service Bus: Prioritize worker

Is it a way to prioritize some Azure Service Bus message consumers among a set? For example, some message processors (workers) are placed on more productive servers, so it would make sense to load them first.

In my case the task is video encoding. There are machines with GPU on board that can also use CPU for processing. So I would like to prioritize GPU threads and keep CPU for some other tasks.

Upvotes: 0

Views: 56

Answers (1)

rickvdbosch
rickvdbosch

Reputation: 15621

In short: no, there is not. However, if some workers are placed on more productive servers they should automatically get more messages since they will be able to process faster, right?

Next to this, there are some Best Practices for performance improvements using Service Bus Messaging. Based on your question, I think your scenario would best be described as a Queue with a large number of receivers:

Goal: Maximize the receive rate of a queue or subscription with a large number of receivers. Each receiver receives messages at a moderate rate. The number of senders is small.

Service Bus enables up to 1000 concurrent connections to an entity. If a queue requires more than 1000 receivers, replace the queue with a topic and multiple subscriptions. Each subscription can support up to 1000 concurrent connections. Alternatively, receivers can access the queue via the HTTP protocol.

To maximize throughput, follow these guidelines:

  • If each receiver is in a different process, use only a single factory per process.
  • Receivers can use synchronous or asynchronous operations. Given the moderate receive rate of an individual receiver, client-side batching of a Complete request doesn't affect receiver throughput.
  • Leave batched store access enabled. This access reduces the overall load of the entity. It also reduces the overall rate at which messages can be written into the queue or topic.
  • Set the prefetch count to a small value (for example, PrefetchCount = 10). This count prevents receivers from being idle while other receivers have large numbers of messages cached.

EDIT:
Based on the addition to the question about GPU vs CPU based workers: it sounds to me that you should use different queues to distinguish between the two. The workloads are explicitly different, so the queues triggering should be as well. This enables you to also scale each type of worker more precisely because you will have a better feel for both of their workloads.

Upvotes: 1

Related Questions