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.
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.