影响服务器运行EventSources

时间:2013-04-08 02:43:38

标签: javascript server-sent-events

我目前正在构建聊天,只是为了好玩。我之前从未这样做过,而且我在一般情况下尝试在JavaScript中试用EventSource API (Server-Sent Events)。我刚刚听说它约3天前,我认为这比设置WebSocket更有趣,也更容易。

我知道漫长的民意调查耗费了大量资源。但是,由于我从未听说过EventSource,它如何影响服务器?它是否耗尽了相同数量的资源?

我注意到在Networks Tab的{​​{1}}中,EventSource会创建一个内容大(随时间变化)的请求。最好有1个内容大的请求吗?

我的聊天目前正在运行两个EventSource。一个用于聊天本身(每个Google Chrome Developers Tool运行)和聊天中的“正在输入...”机制(每2500ms运行一次)。

在聊天大约一分钟后,两个请求的合并内容大小约为250ms。这会增加更多的消息。

我担心我的主人会暂停我的帐户。这是我的一个朋友发生的事情,他使用了民意调查或长期民意调查(我忘了)。我不确定EventSource是否使用尽可能多的资源来进行轮询或长轮询。

主要问题:EventSource如何影响服务器?

  • 它如何使用资源?
  • 除了使用网络套接字之外还有什么更好的东西吗?
  • 有1个请求可以创建大型内容或者有多个请求携带少量数据吗?

2 个答案:

答案 0 :(得分:3)

长轮询比EventSource使用更多资源,因为它不断建立和销毁连接。使用EventSource,只使用一个连接,客户端正在等待数据,而不是检查服务器是否有新数据。

使用长轮询时,客户端将在以下条件下断开连接:

  • 客户不想要更多数据
  • 客户刚刚收到了数据
  • 客户已超时等待数据

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

长轮询

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

<强>的EventSource

  • 客户端在与服务器连接时创建单个套接字
  • 当客户端收到数据时,将保持并重用连接
  • 由客户端使用带有GET标题
  • Accept: text/event-stream请求发起
  • 服从同源限制

<强>的WebSockets

  • 客户端在与服务器连接时创建单个套接字
  • 当客户端或服务器接收数据时,将保持并重用连接
  • 使用带有HTTP GET标题
  • Upgrade: websocket请求启动
  • 可以制作成任何来源(跨域)

资源消耗:

EventSource的开销主要是存在连接。它类似于这种意义上的websockets,其中建立和维护单个连接。因此,由于常量的建立/销毁周期,来自websockets的第二大开销(因为它们是双向的),并且来自EventSource(单向),所以使用长轮询将获得最大的开销。

更好的选择:

对于客户端和服务器之间的实时和双向通信,您实际上没有比websocket更好的东西。这是客户端和服务器正在监听彼此数据的一种解决方案,而不是互相推送数据。

SSE请求

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


总之,大多数主机暂停轮询的原因是由于短轮询和长轮询所需的大量请求。如果使用EventSource或websockets,则使用的是使用套接字的实时通信,这些套接字不会通过请求“垃圾”HTTP服务器。 (如果我发送了100个数据有效负载,EventSource和websockets将使用相同的连接,长轮询将重新连接至少100次)这里你唯一需要注意的是服务器可以处理的最大并发连接数,因为套接字使用比轮询更少的CPU和资源。

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

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

答案 1 :(得分:1)

要了解SSE对服务器的影响,您需要了解它们的工作原理。我将首先解释一下长轮询,因为它是最接近的选择。

长轮询

通过长轮询,客户端向服务器发送请求,服务器保持该状态;如果没有什么可说的,它就不会发送回复。对于您的聊天示例,您可以发送一个请求,其中包含您收到的最新消息的ID,服务器将延迟发送响应,直到他们需要向您发送新消息为止,此时响应将被释放。

缺点是即使没有使用连接并且脚本正在运行(可能不时地轮询DB以获取新消息),连接也会保持活动状态。每次服务器向客户端发送内容时,您仍需要新连接。

与常规民意调查相比,优势在于流量大大减少,因为只有在有话要说时才会给出响应。

服务器已发送事件

SSE非常像长轮询,因为它需要来自客户端的连接,并且只有在有话要说时才发送消息,但最大的区别在于连接没有用第一条消息关闭。显然,不必为每条消息建立新连接是一种胜利,不幸的是,服务器上的负面效果是相似的:连接保持活动状态,服务器脚本保持运行。优点是客户端只发送一个请求。

网络套接字

Web套接字提供真正的双向通信,但保持连接打开的原则是相同的。您可以从这里获得的优势是您可以按照自己的意愿打包信息。

需要注意的是,不同的服务器可以以不同方式处理这些情况。由于它专注于异步事件,无论您使用长轮询,SSE还是Web套接字,NodeJS似乎都更适合作为聊天系统的服务器组件。

至于你的最后一个问题,这在很大程度上取决于你所处的情况以及“更好”的意思。如果更好地意味着更少的网络流量,那么大响应应该比多个短响应少得多。

总结一下:

  • 就CPU而言,长期轮询或网络套接字不是一个非常大的优势/劣势,在网络使用方面比长轮询有一些优势
  • 如果你有时间处理额外的复杂性,
  • 网络套接字仍然是最好的
  • 可能1个请求会更好