Export (0) Print
Expand All

Capacity Planning for Service Bus Queues and Topics

Updated: January 21, 2014

Author: Valery Mizonov and Ralph Squillace

This topic describes:

  • The often-important difference in queue size limits between Azure queues and Azure Service Bus queues and topics

  • How to approximate the correct Service Bus queue capacity when you want to take advantage of Service Bus queue and topic features

  • A test run with messages of different sizes to give some idea of the number of messages of that size that can be placed in a Service Bus queue or topic

Queue and Topic Size Limitations in Azure Service Bus

Both Azure queues and Service Bus queues are implementations of queued access storage, but each has a slightly different feature set, which means you may choose one or the other depending on the needs of your particular application. For example, Service Bus has topics and subscriptions, a pub-sub implementation that is often important in business notification scenarios; whereas Azure queues can store as much as 100 terabytes of data when Service Bus queues are currently limited to 5 gigabytes.

The two major areas of difference – maximum message size and maximum queue size -- are shown below:


Comparison Azure Queues Service Bus Queues

Maximum Message Size

64 KB

Note: This includes the roughly 25% overhead of base64 encoding.

256 KB

Note: This includes both the headers and the body, where the maximum header size is 64 KB.

Maximum Queue Size

100 TB

Note: Maximum size is limited at the storage account level.

1, 2, 3, 4, or 5 GB

The size is defined upon creation of a queue or topic.

This last difference – the 5 GB queue and topic size limit for Service Bus, compared to 100 TB limit for Azure queues – can be fairly important, because it means that if you want to use Service Bus features like deadlettering, topics and subscriptions, rules, or actions, you must assess how much Service Bus queue or topic capacity you will need for your application in advance to build the solid application you want to build. It can be easy for a very active application to create a queue or topic with 5 GB of data depending upon the message size, the size of the message headers, and the size of any custom message properties – and how fast those messages are enqueued or sent to a topic.

Finally, with Service Bus queues, you establish the queue size when you create the queue. You cannot resize the queue after it’s been created; whereas Azure queues have access to so much storage that thinking about increasing the size of the Azure queue is almost not required.

When a queue or topic exceeds its configured capacity, subsequent requests to enqueue a message result in a Microsoft.ServiceBus.Messaging.QuotaExceededException exception. Your application should provide the adequate handling for this particular exception type. For example, one approach would be to temporarily suspend message delivery to a queue or topic and give the consumers enough time to process the backlog before message publication can be resumed.

It is also important to remember that messages in Service Bus queues are comprised of two parts: a header and a body. The total size of the entire message (header + body) cannot exceed 256 KB. The Service Bus brokered messaging API uses binary XML serialization (not text XML), which reduces the output size of the serialized payload, and while this in turn enables storing messages slightly larger than 256 KB, you must test the reduction in size that you see for your own application.

Calculating the Capacity of Service Bus Queues and Topics

Let’s look at the basic algorithm to calculate the size of messages, and therefore what kind of Service Bus queues or topics you might need for your application.

An empty message has a body size of 1024 bytes and default header size of 156 bytes; including other elements, this rounds out to a total of 1635 bytes in a message with no custom headers or properties and an empty message body.

The following formula can be used to estimate the size requirements that the specified number of messages can introduce:

Number Of Messages * (Message Body Size + Message Header Size)

In order to determine the body size, use the BrokeredMessage.Size property. Header size can be trickier, so it depends on how accurate you need to be. The most accurate method is to send the message (or a test message if you need to know the info before sending multiple messages), and then query the queue metadata using the NamespaceManager.GetQueue (or NamespaceManager.GetTopic) method and use the SizeInBytes property (of either the QueueDescription or TopicDescription objects) to determine how much header was added.

Topic size requires a slightly different algorithm. The formula to determine how much space a given number of messages consumes in the topic is:

Number Of Messages * (Message Body Size + (Message Header Size * Number Of Subscriptions))

Note that the size of the header is multiplied by the number of subscriptions to the topic, which means that if any custom headers are added to your topic messages, the topic size will increase in line with the number of subscriptions.

For example, if you had a default message with 200 subscriptions, it results in a topic size of 32 KB. However, if you increase the header size to 600 bytes, the topic size will now be 120 KB. Finally, if you add the ACK messages that flow from each subscription receiver, you’re adding in quite a bit. A single message with a 600-byte header matching 200 subscriptions, add in 200 ACK messages (one for each subscription) and you’re looking at 568,635 bytes. It’s important to have thought about this ahead of time.

Validating Capacity Approximations

You can take the following data into consideration when approximating how many messages you can hold in a single Service Bus queue. This data was captured by a custom utility in order to determine the queue capacity with different message size options.


Sample Message Size 1 GB Queue 2 GB Queue 3 GB Queue 4 GB Queue 5 GB Queue

1 KB






10 KB






50 KB






100 KB






250 KB






To rule out the potential impact of binary XML serialization on the test results, all sample messages were initialized with a byte array of the respective size filled in with random values.

See Also

Community Additions

© 2014 Microsoft