1

We're developing a system that uses SignalR to push out frequent updates of some business important metrics. We'll have a medium number of connected clients, anywhere from 50 to a 1000, and each client will need a unique payload.

Based on a talk Damian Edwards gave, our load profile best matches the Specific Server scale out pattern, where we essentially assign clients to connect to a specific SignalR server in the topology, rather than use a backplane.

Rough pseudo code on how this works is that a client does a GET on our load balanced API URL, whichever server is hit responds back with its URL, and the client then configures the SignalR client library to use that URL to connect.

This looks like it will work great on-premise, but now we are planning for Azure deployments as well. Absent this requirement, Azure Web Sites are a great fit. However, this pattern requires that we can reliably identify individual instances in a Web Site, which we don't see a way to do.

Is this just breaking the abstraction that Azure Web Sites provides? Do we have to use a VM or Web Role to get a reliable, consistent IP or addressable URL for each of our SignalR instances? Or is there another way people have deployed SignalR with Specific Server to Azure.

Peter M
  • 472
  • 5
  • 16
  • 1
    use VM and it will be file. Based on same talk you are in right direction just use VMs and it will give you more control. Try to use VM url that is assigned by Azure like companyname_node01.cloudapp.net – Farrukh Subhani Dec 03 '14 at 21:35
  • Thanks Farrukh. As you said, it looks like we can use VMs or Cloud Services and get a defined, addressable URL to use with a Specific Server design – Peter M Dec 05 '14 at 13:55

1 Answers1

0

The default Azure Websites behavior might actually work for you.

Azure Websites saves an affinity token as a cookie after the first request from a client. That affinity token ensures that all future requests from that client get routed to the same instance of the website.

If you really want to handle the load balancing yourself for some reason, that's also possible. There's an API that lets you get the affinity tokens for all your site instances.

See here for more details: http://blog.amitapple.com/post/2014/03/access-specific-instance/#.VH-KOHl0xUY

Zain Rizvi
  • 23,586
  • 22
  • 91
  • 133
  • Zain, thanks for the info on the affinity token. Sounds plausible, but we are wary of relying entirely on the affinity token. Seems like an implementation detail of the Azure intra-instance load balancing that could change under us. – Peter M Dec 05 '14 at 13:58
  • @PeterM My main point was that what you want is the default behavior of for Azure Websites and that it's something that's unlikely to change in the future (too many people rely on that behavior for it to change). I can see how you might find it more risky to deal directly with the affinity token yourself, but if you ignore it as a behind the scenes implementation detail with the understanding that the default behavior gives you what you need, you get a much more stable situation. – Zain Rizvi Dec 05 '14 at 17:38
  • Thanks for the clarification. While designing our on-premise systems, as a rule we've avoided relying on sticky sessions, but as you said, perhaps we'll reconsider for Azure. – Peter M Dec 05 '14 at 18:40