First published on on Jul 18, 2016
Now that Service Bus Premium Messaging has become generally available, many of our customers are asking "how fast is it?" In order to answer that question, we made a quick performance bench-marking .NET application. The app should give you an idea of what kind of performance to expect with your setup.
We ran 3 different tests from a D4 V2 VM in North Europe with a premium namespace in North Europe as well (placing the resources in the same data center is important). We then ran the tests with 1, 2 and 4 messaging units, with a 1 KB message size. The tests hit 3 different use cases:
A single queue
A single topic with a single subscription
A single topic with 5 subscriptions
You may notice that if you were to create your own application, and just sent messages in a loop, you might not get these results. This app used batching; one of the first things to do when looking to maximize throughput. Additionally, we are using AMQP and we aren't using any advanced features here such as transactions, duplicate detection, or sessions.
Please keep in mind that results will vary. For instance, you may see results with higher or lower throughput than ours. We simply wanted to provide a idea of what you can expect to see.
For reference, here is a link to the
, and here is a link to the code on GitHub:
Below is a summary of what our numbers looked like for
messages to Service Bus:
And here's what it looked like when
With 4 MU's, premium messaging was able to maintain over
messages per second in
The main thing to point out here is the consistency, which is the primary reason to think of premium messaging in the first place. If you can't afford to have messages backed up because of your volume, or to experience higher latencies because your "neighbors are being noisy," then you might want to think about premium messaging.
Either way, we are extremely excited about the results, and can't wait to see what everyone builds with it! Let us know what you think in the comments.