Ajax轮询与SSE(服务器端的性能) [英] Ajax polling vs SSE (performance on server side)

问题描述

从服务器端的角度来看，我很好奇是否何时使用Ajax轮询而不是SSE会有某种标准限制.

I'm curious about if there is some type of standard limit on when is better to use Ajax Polling instead of SSE, from a server side viewpoint.

• 每秒请求1次:我敢肯定SSE会更好
• 每分钟1个请求:我敢肯定Ajax会更好

但是每5秒有1个请求怎么办?我们如何计算Ajax或SSE的极限频率在哪里?

But what about 1 request every 5 seconds? How can we calculate where is the limit frequency for Ajax or SSE?

推荐答案

对于Ajax来说，每分钟1个请求始终没有更好的选择，因此从一开始就存在错误假设.任何一种频繁的轮询几乎总是一种昂贵的选择.从我们先前的对话中，在对另一个问题的评论中看来，您开始时相信开放的TCP套接字(无论是SSE连接还是webSocket连接)以某种方式对服务器性能造成了代价.空闲的TCP连接占用的CPU数为零(也许很长一段时间内，可能每次发送一次保持活动，但除此之外，空闲的套接字不使用CPU).它确实使用了一点服务器内存来处理套接字描述符，但是经过高度调优的服务器可以一次拥有1,000,000个打开的套接字.因此，您的CPU使用率将更多地取决于建立的连接数以及每次建立连接时它们要求服务器执行的操作，而不是所涉及的开放(主要是空闲)连接数.

No way is 1 request per minute always better for Ajax, so that assumption is flawed from the start. Any kind of frequent polling is nearly always a costly choice. It seems from our previous conversation in comments of another question that you start with a belief that an open TCP socket (whether SSE connection or webSocket connection) is somehow costly to server performance. An idle TCP connection takes zero CPU (maybe every once in a long while, a keep alive might be sent, but other than that, an idle socket does not use CPU). It does use a bit of server memory to handle the socket descriptor, but a highly tuned server can have 1,000,000 open sockets at once. So, your CPU usage is going to be more about how many connections are being established and what are they asking the server to do every time they are established than it is about how many open (and mostly idle) connections there are.

请记住，每个HTTP连接必须创建一个TCP套接字(这是客户端/服务器之间的往返)，然后发送http请求，然后获取http响应，然后关闭套接字.每分钟要做很多数据往返.如果连接是https，则由于加密层和端点认证，建立连接的工作和往返更多.因此，当您可以创建一个SSE连接并且客户端仅侦听通过该连接从服务器流式传输的数据时，对成千上万的客户端进行每分钟的所有处理似乎是对资源和带宽的巨大浪费.

Remember, every http connection has to create a TCP socket (which is roundtrips between client/server), then send the http request, then get the http response, then close the socket. That's a lot of roundtrips of data to do every minute. If the connection is https, it's even more work and roundtrips to establish the connection because of the crypto layer and endpoint certification. So doing all that every minute for hundreds of thousands of clients seems like a massive waste of resources and bandwidth when you could create one SSE connection and the client just listen for data to stream from the server over that connection.

正如我在较早的关于另一个问题的评论交流中所说的那样，这些类型的问题在摘要中并没有真正回答.为了开始进行一些计算或测试工具，您必须对客户端和服务器都有特定的要求，并且要对所传递的数据有特定的了解，并且对客户端上的数据有多紧急，因此必须具有特定的轮询间隔和特定的比例.评估哪种可能是更理想的做事方式.只是有太多变量无法提供纯粹的假设答案.您必须定义一个方案，然后分析该特定方案的不同实现.

As I said in our earlier comment exchange on a different question, these types of questions are not really answerable in the abstract. You have to have specific requirements of both client and server and a specific understanding of the data being delivered and how urgent it is on the client and therefore a specific polling interval and a specific scale in order to begin to do some calculations or test harnesses to evaluate which might be the more desirable way to do things. There are simply too many variables to come up with a purely hypothetical answer. You have to define a scenario and then analyze different implementations for that specific scenario.

每秒请求数只是许多可能变量中的一种.例如，如果大多数情况下您轮询的时候实际上并没有什么新内容，那么这对SSE案例将提供更多的优势，因为它根本没有任何事可做(服务器上的零负载，只占用了一点内存).多数情况下是开放的套接字)，而轮询会产生持续的负载，即使无事可做.

Number of requests per second is only one of many possible variables. For example, if most the time you poll there's actually nothing new, then that gives even more of an advantage to the SSE case because it would have nothing to do at all (zero load on the server other than a little bit of memory used for an open socket most of the time) whereas the polling creates continual load, even when nothing to do.

服务器推送(无论是使用SSE还是webSocket实现)的第一大优势是，只有在实际上有相关数据要发送到该特定客户端时，服务器才需要对客户端执行任何操作.在所有其余时间中，套接字只是闲置在那儿(也许偶尔间隔很长时间，发送一个保持活动状态).

The #1 advantage to server push (whether implement with SSE or webSocket) is that the server only has to do anything with the client when there is actually pertinent data to send to that specific client. All the rest of the time, the socket is just sitting there idle (perhaps occasionally on a long interval, sending a keep-alive).

轮询的第一个缺点是客户端可能在很多时候对服务器进行轮询，并且服务器不得不花费资源来处理轮询请求，而只是通知该客户端没有新内容.

The #1 disadvantage to polling is that there may be lots of times that the client is polling the server and the server has to expend resources to deal with the polling request only to inform that client that it has nothing new.

我们如何计算Ajax或SSE的极限频率在哪里?

How can we calculate where is the limit frequency for Ajax or SSE?

这是一个非常复杂的过程.在特定情况下，需要定义许多变量.它不只是每秒请求数那么简单.然后，您必须决定要尝试测量或评估的内容以及规模是多少? 服务器性能"是您唯一提到的内容，但是必须完全定义，并且必须将不同的因素(例如CPU使用率和内存使用率)权衡到要测量或计算的内容中.然后，如果计算无法得出明显的答案，或者如果决策如此关键以至于您想使用真实指标来验证计算，您甚至可能需要运行一些测试工具.

It's a pretty complicated process. Lots of variables in a specific scenario need to be defined. It's not as simple as just requests/sec. Then, you have to decide what you're attempting to measure or evaluate and at what scale? "Server performance" is the only thing you mention, but that has to be completely defined and different factors such as CPU usage and memory usage have to be weighted into whatever you're measuring or calculating. Then, you may even need to run some test harnesses if the calculations don't yield an obvious answer or if the decision is so critical that you want to verify your calculations with real metrics.

听起来您正在寻找一个答案，例如以大于x个请求/分钟的速度，应该使用轮询而不是SSE"，而且我认为没有这么简单的答案.它所依赖的内容远远超出了请求/分钟或请求/秒.

It sounds like you're looking for an answer like "at greater than x requests/min, you should use polling instead of SSE" and I don't think there is an answer that simple. It depends upon far more things than requests/min or requests/sec.

这篇关于Ajax轮询与SSE(服务器端的性能)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！