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