7

I broadcast and receive all messages with 1 worker process IIS. Bump the worker process to 2, I receive only every other messages (lost 50%). Is it by designed, configuration or bug?

Naptime
  • 81
  • 1
  • 2

1 Answers1

13

This is by design. The two worker processes don't share state and clients will be distributed between them on a round-robin basis, which means 50% will connect to process A and 50% to process B. As the underlying SignalR message bus is in-memory by default, process A doesn't see messages from process B.

What you're configuring is called a "web garden" (not to be confused with "web farm") and is commonly used to make faulty applications more responsive (see this SO question). As SignalR is built from the ground up with scalability in mind, this configuration won't give you any benefit.

My recommendation is to keep the worker process limit at 1.

There is however a way to make it working with web gardens: you'd need to use an external message bus like Redis or Windows Azure Service Bus (details can be found in the docs) for sharing messages between the processes, which of course introduces additional network latency.

Community
  • 1
  • 1
Alexander Köplinger
  • 2,497
  • 17
  • 15
  • This exactly answers my question. I have memory leaks problem and have to recycle the application pools periodically. I play with web garden to see if it helps. Thanks. – Naptime Oct 08 '12 at 17:29
  • 1
    Please update this answer with the direct link to the documentation, located at: http://www.asp.net/signalr/overview/performance/scaleout-in-signalr. Additionally, I have one objection: I don't like the recommendation to keep the worker process limit at 1. There's certainly benefits to use more than 1. The documentation will show the user how to make it work with more than 1 worker process without limiting his options. – Icarus Aug 05 '15 at 14:36
  • @lcarus thanks, I added the direct link. I'll leave my recommendation of one worker process though. While a web garden has some advantages in certain use cases, the vast majority of users shouldn't need one. – Alexander Köplinger Aug 06 '15 at 15:22