简体   繁体   中英

SignalR best practices: Notify clients about new data and pull or push new data

I am currently implementing SignalR in my project and I am wondering if I should notify the clients about data changes and let them pull the new data or should I push the new data to the clients?

A bit concerned about the size limitations, what if the data that has to be sent is quite large?

Also what if there are a lot of users around 1000 at once?

Generally, I am looking about the best practices to make sure this works stable.

This is an opinion question so there isn't "an answer", just things to consider.

Definitely depends on how big the data is. You need to think about the fact that you're sending X bytes to N users at R rate. You can do the math to figure out if this will be problematic for performance but "quite large" is relative.

Some things to take into account:

  • General .NET performance overhead. Are you going to cause GC pressure by sending these large messages?
  • How does the serializer handle these types of payloads?
  • Remember that the data needs to be copied into individual connection buffers so are you going to be causing an insane amount of GC's with this scenario?
  • If you're using scale out, I highly recommend against sending large payloads as you're now sending that payload to each of the servers involved in your farm/cluster and it could get chatty.

Other things to consider:

  • Is the data really that dynamic?
  • Does each client need to get the entire dataset of can it be a diff?

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM