In this post I take a different approach. I will simulate a run with 10000 participants. The run is 15K and there are passing time marks at 5 and 10K. At 15K the finishing time will be registered. I will use multiple clients to send messages to Service Bus queue. I will use one client sending 10000 messages for 5K passing mark, one sending 10000 messages for 10K passing mark and one client for 15K finishing times.
I have changed some settings like batch size for WCF-SQL Adapter, which I set to a 1000. For SB-Messaging I have changed the Prefetch Count. I also modified the polling interval of processing host to 50 ms. These are just experimental to increase performance (latency and throughput).
The Prefetch Count specifies the number of messages that are received simultaneously from the Service Bus Queue or a topic. I set this initially to a 1000 to observe what will happen in my BizTalk environment regarding throughput. More on prefetching see the Best Practices for Performance Improvements Using Service Bus Brokered Messaging.
|Number of clients||Number of message per client||Number of messages||Duration (Latency) in seconds||Msg/Sec|
With nine clients the duration to send messages to queue was less 1000 seconds, however BizTalk started throttling and finished processing a 180 seconds later. Still processing of 30000 messages was around 21 minutes. I changed the polling interval of the processing host back to its default of 500 ms. With subsequent test BizTalk throttled again after a few minutes.
BizTalk host BizTalkServerApplication throttled because InflightMessageCount exceeded the configured throttling limit.
With more clients the latency to send message to queue decreases. However, the throughput at the BizTalk end decreases and so does the latency for this complete process. This means performance decreases as BizTalk is not optimized to process that kind of load. Therefore tuning in the dashboard will be required to optimize BizTalk if possible. However, it may be better to consider to scale vertically with VM assigning more cores and memory (i.e. large or extra-large instance) or scale horizontally adding more instances of BizTalk. Scaling will mean incurring more cost as well.
See Pricing Details Windows Azure.
With more clients and more queues you will be able to send up to a 100 or more messages per second to the Service Bus queues (see Scenarios paragraph of Best Practices for Performance Improvements Using Service Bus Brokered Messaging). This can be done easily. However your backend systems (i.e. BizTalk in this scenario) must be able to read and process the message in case performance (high throughput) is a requirement. So scalability will be an important quality attribute in this kind of scenarios. In upcoming posts I will delve into this scenario to further experiment with SB-Queues and Topics.