长轮询是否比传统轮询更具资源效率？
为什么对我来说，保持 http 连接打开直到内容到来然后重新打开连接比简单地定期打开连接更有效？
当然，后一种情况可能更加偶然，但我纯粹是从资源效率的角度来问的。
Why is it more efficient for me to hold an http connection open until content comes and then re-open the connection than to simply open a connection periodically?
Ofcourse the latter scenario is perhaps more hit or miss but I am asking purely from a resource efficiency point of view.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
通过保持连接打开，您可以阻塞资源，但不会产生定期断开连接和建立连接的开销。设置&在函数调用下关闭套接字连接的成本要高得多。将关闭意图发送到连接端点，释放与其关联的内核资源和内存。打开连接时，情况相反。为了分配内核资源，可能存在序列化调用（取决于内核实现），这可能会影响整体系统性能。最后但并非最不重要的一点是，命中与未命中方法不是确定性模型。
By keeping a connection open, you are blocking resources but not incurring the overhead of periodic tearing down connections and setting up connections. Setting & closing a socket connection is lot more expensive underneath the function call. Sending the close intent to the connection end point, freeing the kernel resources and memory associated with it. For opening the connection, the same in reverse happens. For allocating kernel resources, there may be serialized calls (depends on kernel implementation) which can affect the overall system performance. Last but not the least, the hit-n-miss approach is not a deterministic model.
假设您有一个线程阻塞在套接字上等待响应。 （如彗星）。在此期间，线程不会被内核调度，并且机器上的其他东西可以运行。但是，如果您正在轮询，则线程正忙于短暂的等待期。这也会增加延迟，因为在轮询发生之前您不会知道需要执行某些操作。
Let's say you have a thread blocked on a socket waiting for a response. (As in comet). During that time, the thread isn't scheduled by the kernel and other things on the machine can run. However if you're polling the thread is busy with brief wait periods. This also adds latency because you won't know of a need to do something until the poll occurs.