长轮询的 Apache Tomcat 效率如何？答案

【问题标题】：How efficient is Apache Tomcat for Long Polling?长轮询的 Apache Tomcat 效率如何？
【发布时间】：2012-04-03 00:06:15
【问题描述】：

我正在阅读这个Question 关于长轮询的问题，除了提供解决方案之外，还有一个有趣的观点是关于 Apache 处理大量请求的效率低下。我对 Apache Tomcat 有同样的担忧吗？

Apache Tomcat 是否足够高效以处理长轮询。我知道 Apache Tomcat 支持相当多的并发线程，但是它是否扩展到了这样一个限制，以至于我们可以按照上面提到的线程解释的方式将它用于长轮询？

【问题讨论】：

在我看来，我更喜欢使用信号量（自旋锁）的短轮询方法来尽可能处理此类服务。如果您可以牺牲几百毫秒（最坏的情况，通常只有几十毫秒）的准确性，您可以获得支持更多并发用户的好处。
@TravisJ 是的选项之一，但目标是实现类似 Facebook 的功能，我们有实时更新，我们可以从 Facebook 看到客户端总是在发出请求。
facebook的哪个部分？并非所有的 facebook 都是实时内容。您是指实时聊天吗？
不，我的意思是新的提要和通知部分。

标签： tomcat long-polling

【解决方案1】：

你指的是question上的这条评论，

在像 Apache 这样的常规网络服务器上运行它会很快占用所有“工作线程”并且
让它无法响应其他请求

最新版本的 apache tomcat 支持comet，它允许非阻塞 IO 允许 tomcat 扩展到大量请求。从这个article，

感谢 Java 4 的 New 中引入的非阻塞 I/O 功能 Java 平台 (NIO) 包的 I/O API，一个持久的 HTTP 连接不需要不断地将线程附加到它。只有在请求被处理时才能将线程分配给连接处理。当请求之间的连接空闲时，线程可以被回收，连接放在一个集中的 NIO select 设置为检测新请求而不消耗单独的线程。这个模型，称为每个请求的线程，可能允许 Web 服务器处理越来越多的具有固定数量的用户连接线程。在相同的硬件配置下，运行在这种模式的规模比线程每连接模式要好得多。如今，流行的 Web 服务器——包括 Tomcat、Jetty、GlassFish (Grizzly)、WebLogic 和 WebSphere——每个请求都使用线程通过Java NIO。

【讨论】：

centralized NIO select set 是什么意思？

【解决方案2】：

看到这个report comparing Tomcat and Jetty for Comet：

当非常繁忙的连接很少时，Tomcat 的性能往往会稍好一些。它在请求延迟方面略有优势，这在通过几个连接发送许多请求/响应而没有任何显着空闲时间时最为明显。

当有大量空闲时间的连接很多时，Jetty 往往具有更好的可扩展性，就像大多数网站的情况一样。 Jetty 的小内存占用和先进的 NIO 使用允许每单位可用内存有更多的用户。此外，更小的占用空间意味着 servlet 容器消耗的内存和 CPU 缓存更少，并且可以使用更多缓存来加速重要应用程序的执行。

Jetty 在提供静态内容方面也具有更好的性能，因为 Jetty 能够使用高级内存映射文件缓冲区与 NIO 收集写入相结合，以指示操作系统以最大 DMA 速度发送文件内容，而无需进入用户内存空间或JVM。

如果您的应用程序存在空闲连接或客户端只是在等待来自服务器的响应的时间段，那么 Jetty 将是 Tomcat 的更好选择。一个示例包括股票市场代码，其中客户端发送的请求很少，只是在等待更新。

此外，Jetty 团队是 Comet 的先驱，我发现的大多数信息和示例都倾向于仅关注 Jetty。自 2008 年以来，我们一直在 Comet 服务器上使用 Jetty，并且对结果感到满意。

要考虑的另一件事是 Jetty 被设计为独立的 Web 服务器。这意味着您不需要 Jetty 前面的 Apache 服务器。我们在端口 80 上独立运行 Jetty 来处理我们应用程序的所有请求，包括 Comet 请求。

如果您将 Tomcat 用于彗星请求，您很可能需要允许直接访问端口 8080 并绕过 Apache，因为 Apache 可能会否定您的长轮询。

【讨论】：