Thomas
Thomas

Reputation: 29481

Azure Service Bus - Express queues and topics explanations

I've just read this article:

And found an interesting point about Express queues and topics :

Express entities enable high throughput and reduced latency scenarios. With express entities, if a message is sent to a queue or topic is, it is not immediately stored in the messaging store. Instead, the message is cached in memory. If a message remains in the queue for more than a few seconds, it is automatically written to stable storage, thus protecting it against loss due to an outage. Writing the message into a memory cache increases throughput and reduces latency because there is no access to stable storage at the time the message is sent. Messages that are consumed within a few seconds are not written to the messaging store. The following example creates an express topic.

TopicDescription td = new TopicDescription(TopicName);
td.EnableExpress = true;
namespaceManager.CreateTopic(td);

If a message containing critical information that must not be lost is sent to an express entity, the sender can force Service Bus to immediately persist the message to stable storage by setting the ForcePersistence property to true.

If I create an express queue that has only one sender and the sender send BrokeredMessage with the property ForcePersistence = true, is there any interest to create an Express queue ?

I guess this is useless but don't really understand how is it working ...

Any clarification appreciated ^^

Upvotes: 1

Views: 3656

Answers (3)

fer
fer

Reputation: 11

Last couple of days I had to resume some investigation around SB.

In the past, this option help me to improve the throughput. But based on this recent commit in GH, the recommendation around express entities has been removed under title: "removing outdated perf recommendations"

However it seems to be yet available to be configured through ARM and/or AZ-CLI 2.0.

Upvotes: 1

Ranjith Eswaran
Ranjith Eswaran

Reputation: 333

Express Entities like Service Bus Queues and Topics can be created only in standard tiers. Entities created in Premium namespaces do not support the express option. The messages sent to the express entities are cached in the memory instead of storing them immediately in the message store. If the messages persist for more than few seconds then they are written into the message store.So the messages are written into the message store only if they aren't received within the few seconds the messages are received by that entity.

Force persistence property of a message decides whether the message is to be persisted to the database immediately, instead of being held in memory for a short time. This property is ignored if the message is sent to a non-express queue or topic.Refer this link to know more about Force persistence property.

Thus the express entities can be used when there is a need for high throughput and a reduced latency. Refer this link for more information

Upvotes: 1

Sean Feldman
Sean Feldman

Reputation: 25994

There are scenarios where you'd like to have express messages in general and you don't care if the store crashes and they are gone (stock updates for example). But some message types are too important to be lost. You can't mark a message as express. Since queue description dictates if queue is express or not, when handling messages that should not be lost if where in cache and data store crashed, you want to force the persistence flag. This is very handy when you have high message volume and every millisecond of latency counts.

The official documentation explains it will:

Messages that are consumed within a few seconds are not written to the database. Send, Receive, and Complete operations execute faster because these operations only modify the message cache.

Upvotes: 4

Related Questions