我正在尝试扩展一个消息应用程序。我在后台使用带有Socket.io和Redis Store的nodeJS。客户端可以是iphone原生浏览器、android浏览器。。etc
我使用SSL进行节点连接，使用Nginx进行套接字连接的负载平衡。我不是在集群我的socket.io应用程序，而是在10个节点的服务器上进行负载平衡(我们有大量用户)。当传输是Websockets时，一切看起来都很好，但当它回到xhr轮询时(在旧的android手机的情况下)，我在New遗迹中看到了高达3000 rpm的巨大响应时间。我必须每小时左右重新启动一次节点服务器，否则服务器就会崩溃。
我想知道我是否做错了什么，在使用xhr投票传输时，我是否可以采取任何措施来缩放socket.io？比如增加或减少投票持续时间？
您没有做错任何事情，xhr轮询也称为长轮询。这个名字来源于这样一个事实，即连接保持打开的时间更长，通常直到可以发送一些答案。连接关闭后，一个新的连接打开，等待下一条信息。
你可以在这里阅读更多http://en.wikipedia.org/wiki/Push_technology#Long_polling
NewRelic向您显示轮询请求的响应时间。Socket.IO的默认"轮询持续时间"为20秒。
轮询持续时间越短，转速越高；轮询持续时间越多，转速越小。我会考虑增加轮询持续时间，或者只保留20秒的默认值。
此外，为了防止newrelic在长时间轮询中显示不相关的数据，您可以在应用程序中所需的newrelic.js中添加忽略规则。这也在这里的newalent npm模块文档中有详细说明https://www.npmjs.org/package/newrelic#rules-用于命名和忽略请求