16

I am trying to understand how can I make Azure Service Bus Topic to be scaleable to handle >10,000 requests/second from more than 50 different clients. I found this article at Microsoft - http://msdn.microsoft.com/en-us/library/windowsazure/hh528527.aspx. This provides lot of good input to scale azure service bus like creating multiple message factories, sending and receiving asynchronously, doing batch send/receive.

But all these input are from the publisher and subscriber client perspective. What if the node running the Topic can not handle the huge number of transactions? How do I monitor that? How do I have the Topic running on multiple nodes? Any input on that would be helpful.

Also wondering if any one has done any capacity testing with Topic/Queue and I am eager to see those results...

Thanks, Prasanna

phebbar
  • 265
  • 1
  • 3
  • 12

4 Answers4

13

If you need 10K or 100K or 1M or more requests per seconds take a look at what's being done on the highway. More traffic, more lanes.

You can get effectively arbitrary flow rates out of Service Bus by partitioning your traffic across multiple entities. Service Bus gives a number of assurances about reliability, e.g. that we don't lose messages once we took them from you or that we assign gapless sequence numbers, and that has throughput impact on the individual entities like a single Topic. That's exactly like a highway lane just being able to deal with X cars/hour. Make more lanes.

Clemens Vasters
  • 2,666
  • 16
  • 28
  • Thanks Clemens. I had a question on the entities. The article which I had embeded in my original question post also referred to entities. When we say multiple entities, are we referring to entities as topics or queues. So are you suggesting that, instead of publishing the messages onto a single topic/queue, the suggestion is to publish them onto multiple topics/queues? Had one more question. Do we know Azure splits the topics/queues? Would we have one Topic running on a single machine? At what stage does Azure decide to do load balancing to include < 1 node for 10s of topics I might have? – phebbar Aug 30 '12 at 03:11
  • When I say entity I mean either a Queue or a Topic. Each Queue and/or Topic has a storage log and an internal manager that "owns" the entity and makes decision on order and also manages the sequence numbering. The manager runs on one node at any given time, but the association can switch to an other node at a moment's notice. Make 10 Queues like "myQueue-1" to "myQueue-10" and pick a random one as you send. – Clemens Vasters Aug 30 '12 at 06:00
  • Thanks Clemens for giving the clarity around Entity. Couple of reasons I do not like the suggested option by you (Although that might be the way to scale) => 1. When I start I would have only 1000 requests/second and I do not need 10s of Queues. When the customer base grows, may be even 10 queues are not sufficient. Either I would have too many queues or i could also have insufficient queues. 2. I already have 10s of unique topics for passing different kinds of messages. If I have 10 copies of each of these topics, then the number of topics grows. Not sure if that has any other side effect? – phebbar Sep 04 '12 at 08:05
8

Since these replies, Microsoft has released a ton of new capability.

  1. Azure Auto-Scale can monitor the messages in a queue (or CPU load) and start or stop instances to maintain that target.
  2. Service Bus introduced Partitioned Queue's (& topics). This lets you send messages over multiple queues but they look like a single queue to you API. Dramatically increasing the throughput of a Queue.

Before you do that I'd recommend you try:-

  • Async & Batched writes to the queue.
  • Change the Prefetch parameter on the Reads.
  • Also look at Receive.OnMessage() to ensure you get the messages the millisec they are available.

This will improves your perf from ~5 messages / sec to many 100's or 1,000's per sec.

David Lean
  • 123
  • 1
  • 4
  • Is the ~5 messages/sec the max you were seeing for non-partitioned queues? In both .NET and NodeJS? – Peter M Dec 05 '15 at 21:58
3

The Service Bus has its limitations "Capacity and Quotas", check out this article for a very good overview of these: https://learn.microsoft.com/en-gb/azure/service-bus-messaging/service-bus-azure-and-service-bus-queues-compared-contrasted

I suggest you reach out to your local MSFT Specialist if you have a use case that will push the boundaries of Azure Service Bus, MSFT have dedicated teams in Redmond (around the world) that can help you design and push these boundaries at massive scale, this is the Windows Azure CAT (Customer Advisory Team). Their goal is to solve real world customer problems and it sounds like you might have one...

You need to performance and load test to reach all the answers to your questions above based on your specific scenario.

The Azure CAT team have a wealth of metrics on capacity and load testing with the Service Bus (Azure in general), these are not always publicly available so again reach out if you can...

Matthew Steeples
  • 7,858
  • 4
  • 34
  • 49
user728584
  • 2,135
  • 2
  • 21
  • 24
1

If it can handle that many requests, you want to make sure that you receive the messages in such a way that you don't hit the max size of the topic. You can use multiple instances of a worker role in Azure to listen to specific subscriptions so you would be able to process messages faster without getting near the max size.

TheDude
  • 3,796
  • 2
  • 28
  • 51
  • Thanks. I understand about this concept. My question was specifically on the ServiceBus itself - how would it scale if there are 1000s of concurrent requests. – phebbar Aug 30 '12 at 03:16