Performance Considerations

Applies To: Service Bus for Windows Server 1.1

All Service Bus for Windows Server messaging entities (queues, topics, subscriptions) are stored in containers. Each container is associated with only one database, which physically stores the entity and all of its messages. A database can serve one container. If a new container is created, a new database is created as well. When a queue or topic is created, the Service Bus for Windows Server assigns that entity to a container. All messages are stored in that container’s database. All subscriptions to a topic are stored in the same container as the topic.

A Service Bus for Windows Server farm consists of one or three nodes. Each node runs a Service Bus for Windows Server gateway service and a Service Bus for Windows Server broker service. Each of the containers is loaded by one of the brokers. The Service Bus for Windows Server attempts to distribute containers as evenly as possible between all available brokers. If a broker fails, all containers that had been loaded by the failed broker are moved to the remaining brokers. All operations that involve a particular entity are processed by the broker that has loaded the container that contains that entity. For more information, see the Service Bus for Windows Server Architecture Overview1.

Performance Guidelines

This section discusses performance optimizations you can make to improve throughput.

Hardware Considerations

The total throughput of a Service Bus for Windows Server farm is limited by three factors:

1. Computing power of the farm nodes.

2. Computing power and hard disk configuration of the SQL Server machines.

3. Bandwidth of the network connection between the farm nodes and the SQL Server machines.

If you plan on a large number of queues and topics, you should plan for multiple message containers to run on multiple SQL servers. While the Service Bus for Windows Server will dynamically assign message containers (databases) to the farm nodes, the placement of Service Bus for Windows Server queues and topics (with their messages) to databases occurs when creating the entity.

SQL Server Optimizations

The performance of most messaging scenarios is bound by SQL server I/O. Consider the following points when tuning the SQL Server that hosts the Service Bus for Windows Server container databases.

• Configure SQL Server such that logs and data are stored on different disks.

• Optimize the SQL Server hard disks for write performance. If the server is equipped with sufficient memory, SQL Server rarely reads data from disk. If the server is equipped with more than two disks, stripe the disks that contain the log and data stores.

• Pre-allocate space for log and data files and disable auto-growth.

• Configure SQL Server such that there is one TempDB data file for each processor core.

• Change the NTFS allocation unit size to 64 KB.

Enable Redirect

By default, a client sends its request to one of the Service Bus for Windows Server gateways. The gateway forwards the request to the broker that has loaded the container that contains that entity. If the redirect feature is enabled, the client sends a redirect request to the Service Bus for Windows Server gateway. The gateway responds with the address of the broker. The client sends all requests directly to the broker. To enable the redirect feature, set the NetMessagingTransportSettings.EnableRedirect property for the factory to true. For example:

MessagingFactorySettings factorySettings = new MessagingFactorySettings();
factorySettings.NetMessagingTransportSettings.EnableRedirect = true;
MessagingFactory factory = MessagingFactory.Create("address", factorySettings);

Note that the redirect mechanism is available only for requests that are sent via TCP. HTTP requests always go through a gateway. Also note that the redirect feature is not compatible with some load balancers.

Increase Size of Internal Cache

Increasing the cache size allows the Service Bus for Windows Server broker processes to store more data in memory. For example, to increase the default cache size of 500 MB to 1 GB, run the following PowerShell cmdlets on one of the Service Bus for Windows Server farm nodes:

Set-SBRuntimeSetting  -Name messagecachesizeperentity -Value 1048576000
Stop-SBFarm
Start-SBFarm

Disable Message Ordering

Messages sent to a topic must be moved to all subscriptions. This process can be accelerated if the Service Bus for Windows Server is allowed to move messages into subscriptions out of order. Performance improvements of a factor of three have been observed if message ordering is disabled.

To disable messages ordering for a topic, set the TopicDescription.SupportOrdering property of the Microsoft.ServiceBus.Messaging.TopicDescription class to false. For example:

TopicDescription topicDescription = new TopicDescription(topicName)
{
    SupportOrdering = False
};
namespaceManager.CreateTopic(topicDescription);

Scenarios

This section discusses recommendations on how to achieve better performance for several key scenarios. Note that the exact throughput numbers vary widely based on the exact scenario and the specific features used.

Optimizing for Single (or few) Entities with High Throughput

A single queue or topic is stored in a single container, which is based on a single database and handled by a single broker. If the TCP protocol is used, only one of the farm nodes are active; the other nodes of the farm serve as backup nodes that allow the farm to recover from a node failure.

Benchmarks have indicated the following results:

Benchmarks were observed with a three-node farm and a dedicated SQL Server node. The concurrent send and receive of message with a size of 1 KB was measured. All nodes were equipped with four quad-core CPU (2.3GHz), 24GB RAM and 1GBit/s Ethernet.

Optimizing for Many Entities with High Throughput

A three-node farm should have at least three containers. Ideally there are nine (or more) containers, so that the farm nodes stay equally loaded if one of the farm nodes fails.

Our test system was able to handle 1500 queues, of which each had a message throughput (send + receive) of 1 message per second.

See Also

Best Practices for Performance Improvements Using Service Bus Brokered Messaging