So, what's the limit on connections to an MSMQ server?

I get this question now and then from customers who think it will help them work out how many servers they need for their clients. To me it sounds like "How many people can you fit in a Mini?" - although you can probably fit 21 people into one, the car is no longer any use as a transportation device. For MSMQ, if the theoretical limit was 1,000,000 (for argument's sake) you wouldn't want that many clients as the poor server would have been dragged to its knees long before then.

But luckily there is an easy answer - MSMQ has no limit!

Unfortunately the network stack does and everything has to fit into our old friend kernel memory. First the data structures for each connection take up 8KB; next TCPWindowSize is used to configure the receive buffer, usually 64KB; lastly AFD adds an overhead but I don't have numbers for that. So let's assume a rough total of 75KB for each connection - 1,000 active connections means 75MB of kernel memory (on 32-bit platforms that's a significant amount).

I'm on the look-out for some good references to back this up and will edit the blog with anything I find.

[[Edited 19th February, 2010]]

On a related issue, if you find that you have more concurrent clients than you think your system can handle then see if you can make them less ... concurrent.

When MSMQ is sending messages, the queue manager maintains a network connection to the remote destination for several minutes longer than you actually need. This is because MSMQ doesn't know when the last message has been sent so waits an arbitrary amount of time before closing the connection. Establishing a connection is expensive in computing terms and MSMQ tries to minimise the startup overhead. The amount of delay is set by the CleanupInterval registry value and defaults to 5 minutes for clients and 2 minutes for servers.

In a situation where a number of client send messages intermittently but frequently - say, once every 3 to 4 minutes - you can see that the network connection would never drop even though there is relatively little traffic being sent. One approach therefore would be to cut the CleanupInterval to under a minute and the number of concurrent connections should fall away dramatically. The flip-side to this is that the connecting machines will be spending more processing time establishing connections on demand which may impact performance.

Tied up with network connections is the delay MSMQ waits before reconnecting. Depending on the operating system and the WaitTime registry value, MSMQ may wait up to 60 seconds before re-establishing a network connection. So if you want to have connections close quickly but also open just as fast then tweak both registry values.

When MSMQ is receiving messages, the situation is all in the hands of the developer and their application. When an application wants to read a message from a remote queue, a network connection is opened to support the RPC protocol conversation. A common technique is to poll the queue every 10 seconds to see if a message is waiting which keeps the connection alive for as long as the application wants to consume messages. It is therefore very hard to optimise network connections when messages are being read from remote queues.

Comments

• Anonymous
  February 15, 2007
  I know that when I asked this question, what I didn't communicate well was that I meant connections from different computers. Eventually I found out that connections consume one CALs for the duration of the conversation between the MSMQ managers on each machine. So by default the answer was 5.

• Anonymous
  February 15, 2007
  Makes perfect sense. People that ask the question on how many connections you can have on msmq really should step back and re-evaluate their thinking as they probably don't understand queuing theory or asynchronous processing in the first place. So once someone asks that question the first thing I do is question their architecture and their reasons for asking such a question.

• Anonymous
  February 15, 2007
  Hi, DLS, I wasn't responding to any particular question from yourself. The request had appeared from various places in the last few days so I thought it worth researching. As you mention, MSMQ requires Client Access Licenses (CALs) as documented in KnowledgeBase article 183666. Cheers John

• Anonymous
  February 15, 2007
  Hi RussellG, yes, people need to unerstand how MSMQ works so that they can make informed design decisions. Sometimes, though, these questions come in early on when the product is being chosen and before the developers are on board. Whoever is running the project may need to decide between MSMQ and competing technologies such as WebSphereMQ. If MSMQ doesn't have the answer but WebSphereMQ does, even when the question is wrong in the first place, the sale can be lost. I'll look into adding a disclaimer to the posting like "This is not the question you are looking for" or similar. Cheers, John.