运行 EventSources 对服务器的影响 [英] Affects to the server from running EventSources

问题描述

我目前正在构建聊天只是为了好玩.我以前从未这样做过，而且我通常尝试使用 <JavaScript 中的 code>EventSource API(服务器发送的事件).我大约 3 天前才听说过它，我认为它比设置 WebSocket 有趣而且容易得多.

I'm currently building a Chat just for fun. I've never done it before, and I did in in general to try out the EventSource API (Server-Sent Events) in JavaScript. I just heard of it about 3 days ago and I thought it was interesting and far easier than setting up a WebSocket.

我知道长轮询会消耗大量资源.但是，由于我从未听说过 EventSource，它如何影响服务器?它是否使用了相同数量的资源?

I knew that long polling uses up a lot of resource. However, since I've never heard of an EventSource, how does it affect the server? Does it use up the same amount of resource?

我注意到，在 Google Chrome Developers Tool 的 Networks 标签 中，EventSource 确实创建了一个具有较大内容大小的请求(随着时间的推移).是否最好有 1 个内容大小较大的请求?

I've noticed that in the Networks Tab of the Google Chrome Developers Tool, the EventSource does creates a request with a large content size (over time). Is it better have 1 request with a large content size?

我的聊天当前正在运行两个 EventSource.一个用于聊天本身(每 2500 毫秒 运行一次)和正在输入.."聊天机制(每 250ms 运行一次).

My chat currently is running two EventSource's. One for the chat itself (running every 2500ms) and for the "is typing.." mechanism on the chat (running every 250ms).

在聊天大约一分钟后，两个请求的合并内容大小约为 150kb.但是，这会增加更多消息.

After about a minute of being on the chat, the combined content size of the two requests is about 150kb. This will increase the more messages there are though.

我担心我的房东会暂停我的帐户.这就是我一个使用轮询或长轮询(我忘记了)的朋友发生的事情.我不确定 EventSource 使用的资源是否与轮询或长轮询一样多.

I'm afraid that my host will suspend my account. This is what happened to a friend of mine who used polling or long polling (I forgot). I'm not sure if an EventSource uses as much resources as polling or long polling does though.

• 它如何使用资源?
• 除了使用网络套接字还有什么更好的方法吗?
• 是 1 个请求会创建大量内容还是多个请求携带少量数据更好?

推荐答案

长轮询比 EventSource 使用更多的资源，因为它不断地建立和破坏连接.使用 EventSource，只使用单个连接，客户端等待数据，而不是检查服务器是否有新数据.

Long polling uses more resources than EventSource because it is constantly establishing and destroying connections. With EventSource, only a single connection is used, and the client is waiting for data, instead of checking the server for new data.

使用长轮询时，客户端将在以下情况下断开连接:

When using long polling, a client will disconnect under these conditions:

• 客户不想要更多数据
• 客户端刚刚收到它的数据
• 客户端等待数据超时

当服务器没有数据时，客户端会一直等到超时，直到服务器有数据.如果有数据，客户端断开连接并创建另一个连接.如果客户端超时，客户端将断开连接并建立另一个连接.因此，您可以从许多地方看到头顶.

When the server has no data, a client will wait until its timeout until the server has data. If there is data, the client disconnects and creates another connection. If the client times out, the client will disconnect and establish another connection. Therefore you can see overhead from many places.

长轮询

• 如果客户端需要数据，它会建立一个新的连接
• 如果客户端超时，它会重新创建另一个连接
• 如果客户端收到信息，它会重新创建连接

事件源

• 客户端在与服务器连接时创建一个套接字
• 当客户端接收到数据时，连接被维护和重用
• 由客户端使用带有 Accept: text/event-stream 标头的 GET 请求发起
• 遵守同源限制

WebSockets

• 客户端在与服务器连接时创建一个套接字
• 当客户端或服务器接收到数据时，连接被维护和重用
• 使用带有 Upgrade: websocket 标头的 HTTP GET 请求发起
• 可以创建到任何来源(跨域)

资源消耗:

EventSource 的开销主要只是连接的存在.从这个意义上说，它类似于 websockets，其中建立和维护单个连接.因此，由于持续的建立/销毁周期，您将使用长轮询获得最多的开销，其次是来自 websocket 的开销(因为它们是双向的)，而来自 EventSource 的开销最少，这是单向的.

The overhead of EventSource is mainly just the existence of a connection. It is similar to websockets in this sense, where a single connection is established and maintained. Therefore, you will receive the most overhead using long polling, due to the constant establish/destroy cycle, the second most overhead from websockets (since they are bidirectional), and the least from EventSource, which is one-way.

更好的选择:

对于客户端和服务器之间的实时和双向通信，您真的没有什么比 websocket 更好的了.这是客户端和服务器相互侦听数据而不是相互刺激数据的一种解决方案.

For realtime and bidirectional communication between a client and server, you don't really have anything better than a websocket. It is the one solution where the client and server are listening for data from each other, instead of prodding each other for data.

SSE 请求

我认为您问这个问题的前提是您认为 Chrome 中显示的内容是单独的请求.由于 EventSource 与服务器建立了套接字，因此您实际上是在读取通过 EventSource 套接字发送的累积数据量.因此，当您发送数据时，您正在重用相同的连接，您无需担心请求大小.

I think you're asking this question on the assumption that you think what's displayed in Chrome are individual requests. Since EventSource establishes a socket with the server, you are actually reading the cumulative amount of data sent through an EventSource socket. Therefore, when you send data, you're reusing the same connection, and you don't need to worry about request size.

总而言之，大多数主机暂停轮询的原因是因为短轮询和长轮询都需要大量请求.如果您使用 EventSource 或 websockets，则您使用的是使用套接字的实时通信，它不会向 HTTP 服务器发送垃圾邮件"请求.(如果我发送了 100 个数据有效负载，EventSource 和 websockets 将使用相同的连接，长轮询将至少重新连接 100 次)您在这里唯一需要注意的是您的服务器可以处理的最大并发连接数，因为套接字比轮询使用更少的 CPU 和资源.

In conclusion, the reason most hosts suspend for polling is because of the large amount of requests that both short and long polling require. If you use EventSource or websockets, you are using real-time communication that uses sockets, which don't "spam" the HTTP server with requests. (if I sent 100 data payloads, EventSource and websockets will use the same connection, long polling will have reconnected at least 100 times) The only thing you will have to watch here is the maximum amount of concurrent connections your server can handle, because sockets use less CPU and resources than polling.

需要考虑的关于 EventSource/SSE 的事情:

Things about EventSource/SSE to take into consideration:

• 使用传统的 HTTP 协议，websockets 没有
• 对浏览器的支持比 websockets 少，但对不支持的浏览器有 polyfills
• 内置了对重新连接和事件的支持
• 与 websockets 相比具有更简单的协议

这篇关于运行 EventSources 对服务器的影响的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！