我正在尝试扩展消息应用程序。我在后端使用带有 Socket.io 和 Redis-Store 的 NodeJS。客户端可以是iphone原生浏览器、android浏览器..等
我使用 SSL 进行 Node 连接，使用 Nginx 来负载平衡套接字连接。我没有对我的 socket.io 应用程序进行集群，而是对 10 个 Node 服务器进行负载平衡(我们有大量用户)。当传输是 Websockets 时，一切看起来都很好，但是当它回落到 xhr-polling 时(对于旧的 Android 手机)，我在 New-relic 中看到高达 3000 rpm 的巨大响应时间。而且我必须每小时左右重新启动我的 Node 服务器，否则服务器就会崩溃。
我想知道我是否做错了什么，以及在使用 xhr-polling 传输时是否可以采取任何措施来扩展 socket.io？比如增加或减少民意调查持续时间？
最佳答案
你没有做错什么，xhr-polling也称为长轮询。这个名字来源于这样一个事实:连接保持开放的时间更长，通常直到可以通过线路发送一些答案为止。连接关闭后，会打开一个新连接等待下一条信息。
您可以在此处阅读更多相关信息 http://en.wikipedia.org/wiki/Push_technology#Long_polling
New Relic 显示轮询请求的响应时间。 Socket.IO 的默认“轮询持续时间”为 20 秒。
如果轮询持续时间较短，您将获得较高的 RPM；如果轮询持续时间较长，您将获得较小的 RPM。我会考虑增加轮询持续时间或仅保留 20 秒默认值。
此外，为了防止 New Relic 在长轮询中显示不相关的数据，您可以在应用程序中所需的 newrelic.js 中添加忽略规则。 newrelic npm 模块文档中对此也有详细介绍 https://www.npmjs.org/package/newrelic#rules-for-naming-and-ignoring-requests
关于node.js - 使用 xhr-polling 时 Socket.io 的服务器响应时间过长，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/22169952/