timer - 信号R开销

Question

我有一个客户端，它通过定期（每 4 秒）发送它的新位置来更新它在服务器上的位置。我还有一个客户端，它通过定期轮询服务器（每 5 秒）并获取最新位置来跟踪以前的移动设备。

这种通信应该通过 SignalR（用于发送最新位置）还是使用计时器进行？我这么说是因为 SignalR 有一些开销，会产生更大的请求大小，这可能会非常昂贵。

谢谢你，瑞安

Answer 1

HTTP communication win

Right now, based on what I understand of your description, you're doing multiple update POSTs and then listeners are using polling GET requests. These have the overhead of separate HTTP requests with headers and, if not using keep-alive or exceeding the keep-alive timeout, [re-]establishing a TCP connection.

Using SignalR you will instead be able to, at bare minimum, improve the polling GET side of things because SignalR can use long polling which will funnel back multiple responses over a single HTTP GET request and do it in "real-time" rather than always having a hard 4sec lag time. From there you can work your way up through Server Sent Events (SSE) to full blown web sockets depending on the client and server capabilities. Any of these approaches should be more efficient than your currently described implementation.

Request size win

There's only a small "envelope" around each SignalR message. Compared to HTTP headers your browser clients are most certainly having to send with each update POST and polling GET right now I think SignalR will win this easily. Obviously the payload of the message would be the same JSON in either case, so that's a wash.

Programming model win

Most importantly, I think, using SignalR gives you a programming model that abstracts you from what exact underlying techniques end up being used and presents you with a consistent real-time communication API rather than having to ultimately worry about thunking down to a disconnected request/response model.