从服务器端的角度来看，我很好奇何时使用 Ajax 轮询而不是 SSE 是否有某种标准限制。
- 每秒 1 个请求：我很确定 SSE 更好
- 每分钟 1 个请求：我很确定 Ajax 更好
但是每 5 秒 1 个请求呢？我们如何计算 Ajax 或 SSE 的极限频率在哪里？
问问题
964 次
2 回答
7
对于 Ajax 来说，每分钟 1 个请求永远不会更好，所以这个假设从一开始就是有缺陷的。任何一种频繁的轮询几乎总是一个代价高昂的选择。从我们之前在评论中的对话看来另一个问题是，您从相信打开的 TCP 套接字（无论是 SSE 连接还是 webSocket 连接）在某种程度上对服务器性能造成高昂的代价。一个空闲的 TCP 连接占用零 CPU（可能每隔一段时间，可能会发送一次保持活动，但除此之外，空闲套接字不使用 CPU）。它确实使用了一些服务器内存来处理套接字描述符，但是经过高度调整的服务器一次可以有 1,000,000 个打开的套接字。因此，您的 CPU 使用率将更多地取决于正在建立的连接数以及每次建立连接时它们要求服务器做什么，而不是关于有多少打开（并且大部分是空闲）连接。
请记住，每个 http 连接都必须创建一个 TCP 套接字（客户端/服务器之间的往返），然后发送 http 请求，然后获取 http 响应，然后关闭套接字。这是每分钟要做的大量数据往返。如果连接是 https，则由于加密层和端点认证，建立连接的工作量和往返次数就更多了。因此，当您可以创建一个 SSE 连接并且客户端只是侦听通过该连接从服务器流式传输的数据时，每分钟为数十万客户端执行所有这些操作似乎是对资源和带宽的巨大浪费。
正如我在之前关于另一个问题的评论交流中所说，这些类型的问题在摘要中并不能真正回答。您必须对客户端和服务器都有特定的要求，并且对正在交付的数据以及它在客户端上的紧急程度有特定的了解，因此必须有特定的轮询间隔和特定的规模，以便开始进行一些计算或测试工具评估哪种方式可能是更理想的做事方式。变量太多，无法得出一个纯粹假设的答案。您必须定义一个场景，然后分析该特定场景的不同实现。
每秒请求数只是众多可能变量之一。例如，如果大多数时候你轮询实际上没有什么新东西，那么这给 SSE 案例带来了更多的优势，因为它根本没有任何事情可做（服务器上的零负载，除了一点点内存用于大多数时候是一个打开的套接字），而轮询会产生持续的负载，即使无事可做。
服务器推送的第一大优势（无论是使用 SSE 还是 webSocket 实现）是服务器只需要在实际有相关数据发送到特定客户端时才需要对客户端执行任何操作。其余时间，套接字只是闲置在那里（也许偶尔会在很长的时间间隔内发送保持活动状态）。
轮询的 #1 缺点是客户端可能会多次轮询服务器，而服务器必须花费资源来处理轮询请求，只是为了通知客户端它没有任何新内容。
我们如何计算 Ajax 或 SSE 的极限频率在哪里？
这是一个相当复杂的过程。需要定义特定场景中的许多变量。它不像请求/秒那么简单。然后，您必须决定要测量或评估的内容以及规模？“服务器性能”是您唯一提到的内容，但这必须完全定义，并且必须将 CPU 使用率和内存使用率等不同因素加权到您正在测量或计算的任何内容中。然后，如果计算没有产生明显的答案，或者如果决策非常关键以至于您想使用真实指标验证计算，您甚至可能需要运行一些测试工具。
听起来您正在寻找诸如“在大于 x 请求/分钟时，您应该使用轮询而不是 SSE”之类的答案，但我认为没有那么简单的答案。它取决于比请求/分钟或请求/秒更多的东西。
于 2019-04-30T01:39:13.077 回答
1
“轮询”会给各方带来开销。如果可以避免，请不要投票。
如果 SSE 是一个选项，它可能是一个不错的选择。“这取决于”。
问：您的应用需要处理什么样的（如果有的话）“事件”？
于 2019-04-29T20:11:12.887 回答