Playframework 长轮询是否有连接限制？

我正在开发一个使用长轮询的Play1.2.4应用程序，类似于聊天示例。 我一直在用JMeter进行负载测试，当我有300多个侦听器时，我的服务器需要4秒以上的时间来回答，这对我的需要来说太多了，或者侦听器从未收到答案。 我需要在不到一秒钟内得到所有的回答

长轮询是否有连接限制？ 我需要特殊的配置或服务器吗

---

提前感谢，

无需特殊配置，只需服务器上的CPU/RAM加上处理控制器调用所需的时间、对数据库的请求数量等

由于播放是无状态的，如果您遇到超时，只需尝试在负载平衡器后面添加第二台服务器，这应该可以解决问题

根据评论编辑：

您面临的主要问题是，播放需要很长时间才能将事件传播到300个用户。这是意料之中的，因为聊天示例使用内存中的系统进行传播，将消息按顺序传递给每个订阅者

聊天方法还有另一个好处：如果使用第二台服务器，消息不会在它们之间共享，因为ArchivedEventStream存储在本地的Play实例JVM中

---

如果希望获得更高的性能，则需要将发布/订阅步骤移动到外部消息队列工具，如Redis。这样做的好处是，您可以添加额外的实例，同时在它们之间共享相同的消息。

听起来您在播放服务器上进行长时间轮询并没有达到连接限制。相反，您可能正在达到某种形式的瓶颈，这会导致响应时间降低

一种很有可能的情况是，您正在执行JMeter测试的机器上达到一个极限，如果您在GUI模式下运行，这种可能性会增加。您可以通过使用多台机器重复测试来验证是否存在这种情况，只需同时在两台机器上执行相同的测试，如果它们都显示与仅运行一个测试时相同的结果，那么逻辑上问题不在于您的播放服务器，而在于测试本身。但是，如果在运行两个测试时看到更糟糕的结果，那么问题出在服务器上。记住使用一个上升时间，这将有助于确定事情开始减速的点，这对调优很有用

---

如果您达到JMeter限制，那么尝试从命令行运行，这会更有效，或者，如果您确实想要界面，那么尝试使用更少的侦听器，这些都是导致问题的原因。

我没有超时。问题是，当有300多个用户时，长轮询需要3秒钟以上才能响应所有用户，这对我来说太难了。也许你应该输入你正在使用的代码，以便我们可以帮助你，我的应用程序基于Play 1.2.4的聊天示例，我用该示例进行了测试。