通过 Tomcat Advanced I/O 获得高性能的 Ajax(从IBM转)

styxmx

　　浏览器通过发送请求和显示来自服务器的响应与 Web 服务器进行通信。这似乎不是很重要，但从几个方面考虑，它都与本文相关。
　　富
Web 应用程序逐渐尝试提供一些与请求/响应模型不同的功能。Ajax
框架由底层的请求/响应模型抽象而来，它提供了一种运行在客户端的类似于图形用户界面（GUI）的模型。它像一个本地的重量级 Microsoft®
Windows® 或 KDE 应用程序。这意味着您可以创建响应事件的代码，而不是响应请求的代码。细粒度的事件处理对富用户界面至关重要。

Ajax 资源中心 　　请访问 Ajax 资源中心 ，这是有关 Ajax 编程模型信息的一站式中心，包括很多文档、教程、论坛、blog、wiki 和新闻。任何 Ajax 的新信息都能在这里找到。

　　但在底层，仍然有一个请求/响应模型。这不仅是一个有限制的编程模型 — 您可以使用 API 抽象处理它 — 在很多情况下，它还导致性能问题，并且损害服务器在繁忙时控制资源的能力。如果不按照它的设计初衷使用，该模型还会导致更严重的问题。
　　例如，浏览器客户端期望收到关于服务器更改的通知。这原先是不可能实现的；您只能每隔 5 分钟重新加载整个页面来模仿这个行为。因为引入了 JavaScript 代码和 Ajax，所以能够以更高效更美观的方式让页面实现更改通知。
　　页面可能会定期轮询服务器，从而创建大量的服务器请求，以及事件和通知之间的大幅度延迟。或者它可以在等待响应时，始终为服务器打开一个连接。第二个模型称为长轮询
：本文将讨论这一轮询模型 — 因为它以最快的速度响应服务器上的事件 — 以及一些需要克服的困难。
　　在
典型的 servlet
模型中，一个打开的连接意味着一个不执行任何操作的专用线程，它将一直等待，直到在响应事件时更新客户端。线程还是比较耗费资源的，一个服务器上可用的线
程是有限制的。并发访问的增加会快速消耗服务器上的资源。单个的访问不只是意味着一些偶然的页面请求；它还意味着在访问期间有一个持续打开的连接（带有等
待线程）。如果有几百个访问者在他们离开电脑时不关闭浏览器，就会带来一些问题。抽象并不能解决这样的性能问题。
　　解决方案

　　低
级别的问题可以在低级别的 API 中找到解决方案。在坚持使用请求/响应模型的同时，您可以使用非阻塞
I/O（NIO）来保持连接的打开状态，而不需要浪费等待线程。为了方便在 servlet 中使用 NIO，您需要一个基于事件的
API，它会在打开的连接上适时发出恰当的读写行为。Tomcat 6 提供的 CometProcessor API
为这种基于事件的模型提供了便利。本文引入了 CometProcessor API。

回页首

　　

　　NIO

　　首
先，您需要对 NIO 有一定的了解。在典型的阻塞 I/O（blocking
I/O）中，您始终从一个线程中读取流，并且该线程会一直等待，直到整个流完成。对于需要在一次迭代中处理的、生命周期很短的流而言，这很有效：开始读取
数据直到读完所有数据，然后关闭连接。这在一次的迭代中占有很少时间，所以只是短时间占用系统资源。大量并发的短生命周期连接不会造成问题。
　　为了获得通知，您需要一个机制，它只在需要读时才读，需要写时才写，但又保持连接打开，以迅速响应发生的事件。为了便利这个过程，要用到 NIO，它已是 1.4 版本以后的 Java™ 语言的一部分。
　　通过使用 NIO，就会在流完成之后才遍历它。在没有可用数据时才遍历流，这样就可以让流执行其他工作。当发生影响流的事件时 — 例如，进入更多的数据 — 您将继续遍历流。清单 1 展示了一个针对这种事件的示例处理程序；注意 is.available()
。
　　
清单 1. 针对 InputStream的单个读迭代

InputStream is = request.getInputStream(); byte[] buf = new byte[512]; do { int n = is.read(buf); //can throw an IOException if (n > 0) { //read n bytes } else if (n < 0) { //error return; } } while (is.available() > 0);

　　您可以以类似的方式使用 OutputStream和 Writer
。确保在执行写迭代后刷新数据；否则，它将滞留在缓冲区中，直到向流写入下一次迭代。

回页首

　　

　　Comet

　　本
文关注的是 Tomcat 6，它的 Advanced I/O 模块支持 NIO。Jetty 也有类似的功能，但 API
不同。当然，您不希望编写一个特定于某个容器实现的解决方案。即将发布的 Servlet 3.0
规范将带来好消息：当它由通用的容器实现时，会有一个标准的机制来支持基于事件的 NIO。
　　现在，通过特定于 Tomcat
的 CometProcessor 可以更方便地使用这一功能。在 Servlet 3.0 规范发布之前试一试 Tomcat
是很有价值的。如果想建立自己的框架，Tomcat 实现是很好用的；因此本文使用它。Jetty
实现与现有的框架和解决方案紧密集成，如果想在不深入了解技术细节的情况下使用 Comet 的其他功能，它是比较实用的选择。在 参考资料中有另一篇文章，它通过 WebSphere® Community Edition 展示了类似的技术。
　　要在 Tomcat 6.0 上使用 CometProcessor，必须进行两处更改：一是配置，二是代码。
　　首先，在 server.xml 文件中找到连接器。它类似于：

<Connector connectionTimeout="20000" port="8080" protocol="HTTP/1.1" redirectPort="8443"/>

　　使用下面的内容替换 HTTP/1.1 协议：

<Connector connectionTimeout="20000" port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol" redirectPort="8443"/>

　　第二步是通过 servlet 实现 org.apache.catalina.CometProcessor接口。这个接口要求实现一个称为 event()的方法。在第一步中配置的 Http11NioProtocol调用 event()方法来处理请求，而不是 doGet或 doPost
。
　　最基本的支持 Comet 的 servlet 实现如清单 2 所示。
　　
清单 2. 处理基本的 Comet 事件

package eu.adriaandejonge.comet; import java.io.IOException; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import org.apache.catalina.CometEvent; import org.apache.catalina.CometProcessor; import org.apache.catalina.CometEvent.EventType; public class CometServlet extends HttpServlet implements CometProcessor { public void event(CometEvent event) throws IOException, ServletException { if(event.getEventType() == EventType.BEGIN) { // fill in code handling here } // and continue handing other events } }

　　当连接开始时（BEGIN
）、每次新数据可用时（READ
），以及连接结束时（END
），抛出该事件。这是理想的流程。如果出现错误，将接收到一个 ERROR事件，它可能有几个子事件类型。例如，为了记录日志或调查事务回滚的需求，将 TIMEOUT事件从 SERVER_SHUTDOWN事件分离出来是很有意义的。
　　Comet
允许针对不同的事件指定不同的连接超时。这意味着可以给常规的请求设置很短的生命周期，但是对于响应长轮询请求的机制，也可以将这个生命周期延长至几分
钟。这样，您就不会犯下为了方便长轮询而延长所有超时的错误。当常规的请求没被恰当地终止并保持挂起时，这种错误会导致意外的麻烦。

回页首

　　

　　Ajax 处理

　　看一下代码示例，接收 CometEvent好像比处理常规请求要困难得多。在某种程度上，的确如此。至少，工作量增加了。一个单一请求被分成多个阶段，因此，现在不是处理单一的 doGet
，而是必须处理一个 BEGIN
、至少一个 READ
，以及一个 END
。
　　造成这种复杂性的部分原因是出现了一种常见的错误：通过大量的 if语句捕捉所有处理逻辑来实现 event()方法。问题并不完全归结在 if语句上，if语句中代码的数量才是最关键的。除了代码的可维护性外，这个方法还有其他缺陷。
　　当数据可用时，if
语句使您可以从连接进行读取，然后马上处理请求。这并不适合于通知机制。您需要采用另一种方式：在事件发生前（您希望向客户端发送新信息来响应它），连接
应该保持打开。这可以通过几种方式来实现，但它们有一个共同点：它们都引入了恰当的对象模型，该模型处理程序逻辑而不是捕捉 if语句中的所有代码。
　　其中的一种方法是保持一个中央队列，并在事件发生时使用它来发送所有通知。然后，由客户端负责重新连接到该队列。然而，对于 END或 ERROR事件，CometProcessor需要从该队列注销连接。如清单 3 所示。
　　
清单 3. 注册 Comet 事件

package eu.adriaandejonge.comet; import java.io.IOException; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import org.apache.catalina.CometEvent; import org.apache.catalina.CometProcessor; import org.apache.catalina.CometEvent.EventType; public class CometServlet extends HttpServlet implements CometProcessor { private static final long serialVersionUID = 3616604581787849064L; private static final String EVENT_REGISTRY = "event.registry"; private EventRegistry eventRegistry; public CometServlet() { eventRegistry = (EventRegistry) this.getServletContext() .getAttribute(EVENT_REGISTRY);                           }    public void event(CometEvent event) throws IOException, ServletException { HttpServletRequest request = event.getHttpServletRequest(); HttpServletResponse response = event.getHttpServletResponse(); if(event.getEventType() == EventType.BEGIN) { eventRegistry.register(request, response); } else if(event.getEventType() == EventType.END) { eventRegistry.deregister(request, response); } else if(event.getEventType() == EventType.ERROR) { eventRegistry.deregister(request, response); } }          }

　　另一种办法是保持一个中央 ListenerRegistry
，
客户端可以将它用作事件监听器。不同之处是在事件通知之后连接仍然保持打开。NIO
允许随后再返回到这个连接并发送额外的数据。在客户端，您可以使用标准的 API（比如 Bayeux）来支持这一功能。但当前，它是由 Dojo
实现的，并且和 Jetty Comet 实现结合使用可以获得最好的效果。
　　Comet 主要是服务器端技术。在客户端，处理请求和常规请求差不多。为了进行演示，清单 4 测试了最基本的 Ajax 请求：来自 Wikipedia 的典型的基于 XMLHttpRequest的示例。它能够很好地响应来自 Comet 服务器的事件。
　　
清单 4. 发送一个 Ajax 请求

<script> function ajax(url, vars, callbackFunction) { var request =  new XMLHttpRequest(); request.open("POST", url, true); request.setRequestHeader("Content-Type", "application/x-javascript;"); request.onreadystatechange = function() { if (request.readyState == 4 && request.status == 200) { if (request.responseText) { callbackFunction(request.responseText); } } }; request.send(vars); } function testFunction(myText) { alert("myText = " + myText); } </script> <input type="button" caption="test" >

　　这表明您可以使用其他框架（比如 Prototype）来处理 Comet 事件。然而，阅读 Bayeux 规范并了解更加规范化的事件交互协议是一个有趣的实践。

回页首

　　

　　总体性能调优

　　将
队列或事件监听器与 CometProcessor
结合使用能够节省大量打开的线程，但这个方法不能控制某些并发线程的数量（这些线程处理将要返回给浏览器的页面）。因此，服务器可能面临大量需要同时处理
的请求。由 CometProcessor 接口引入的基于事件的模型也有助于改善总体性能。
　　解决方案是引入一个机制，它不做其他工作，而是尽快地处理事件，然后通过 WorkerQueue注册这些事件并结束处理。同时，您必须运行一定数量的 WorkerThread
，它们从 WorkerQueue获取请求，然后逐个处理它们。这样，处理将要返回给浏览器的页面的并发线程比实现相同目的的 WorkerThread要少。
　　当
请求的数量增加，并且工作线程的数量太少时，处理请求则需要很长时间。但在能承受的负载范围内，服务器不会（至少很少）崩溃。请求处理时间和队列长度是一
个很好的度量指标，系统管理员通过监控它们来决定是增加服务器，还是关掉多余的服务器。这种处理请求的方法在云计算环境中表现很出色。
　　将 Comet 事件传递给处理函数机制的代码如清单 5 所示。本示例省略了队列的实际处理过程，因为它特定于您的需求，并涉及到许多微妙的并发性问题。但它展示了如何通过更加面向对象的解决方案来实现很大的 if语句。要想进一步增强面向对象特性，可以将 if语句的最后一小部分替换为 Map
，后者将 EventType连接到 EventHandler工厂对象。但本示例只展示总体思路。
　　
清单 5. 在一个 EventWorker队列上注册 Comet 事件

package eu.adriaandejonge.comet; import java.io.IOException; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import org.apache.catalina.CometEvent; import org.apache.catalina.CometProcessor; import org.apache.catalina.CometEvent.EventType; public class CometServlet extends HttpServlet implements CometProcessor { private static final long serialVersionUID = 365737675389366477L; private static final String EVENT_WORKER = "event.worker"; private EventWorker eventWorker; public CometServlet() { eventWorker = (EventWorker) this.getServletContext() .getAttribute(EVENT_WORKER); } public void event(CometEvent event) throws IOException, ServletException { HttpServletRequest request = event.getHttpServletRequest(); HttpServletResponse response = event.getHttpServletResponse(); if (event.getEventType() == EventType.BEGIN) { eventWorker.enqueue(new BeginEvent(request, response)); } else if (event.getEventType() == EventType.READ) { eventWorker.enqueue(new ReadEvent(request, response)); } else if (event.getEventType() == EventType.END) { eventWorker.enqueue(new EndEvent(request, response)); } else if (event.getEventType() == EventType.ERROR) { eventWorker.enqueue(new ErrorEvent(request, response)); } } }

　　

回页首

　　

　　处理常规请求和 Ajax 请求

　　一个更通用的场景要求您同时处理常规请求和 Ajax 请求。
一些 Ajax 请求必须立即处理，其他 Ajax 请求应该作为长轮询处理，普通的请求应该发布到 WorkerQueue
。
　　可
以创建多个 servlet 来处理这些不同的请求，并设定各个 servlet 的任务。但问题是，对本文前面定义的整个 HTTP
连接器而言，连接超时是一样的 —— 至少为超时配置的值是一样的。Comet
事件允许为每个请求指定另一个连接超时。这需要进行动态计算，但当为不同的 servlet 指定不同的值时，它能提供帮助。

回页首

　　

　　结束语

　　在处理 Ajax 请求和常规请求期间优化服务器的性能，就像实现 CometProcessor接口和向 server.xml 文件添加不同的协议处理函数一样简单。但是，要管理请求处理，则需要软件开发技巧。您需要考虑队列、事件监听器、工作线程，以及注册和注销请求/响应。
　　如果您亲自开发自己的框架，就必须克服这个困难，以获得更加稳定的、性能更佳的服务器。但如果您开发的是一个简单的 Web 应用程序，复杂的事件处理则不仅仅是耗费额外的资源。
　　对于后一种情况，最好的办法是对事件通知请求限制 CometProcessor的使用，而其他所有请求则可以依靠典型的 doGet和 doPost
。
　　注意关注 Servlet 3.0 规范的发布。它可能鼓励进一步在 Web 服务器上采用 NIO。
　　

　　参考资料

• 您可以参阅本文在 developerWorks 全球网站上的 英文原文
  。
  
• The Tomcat Advanced I/O文档提供了更多的背景信息。
  
• 关注即将发布的 Java Servlet 3.0 Specification
  。
  
• 在 “Developing Rich Internet Applications for WebSphere Application Server Community Edition
  ” 中查看 NIO 的另一个示例，它在 WebSphere Community Edition 上使用类似的技术（developerWorks，2008 年 9 月）。
  
• 获得更多关于 Jetty的信息，它是一个完全用 Java 实现的开源的、基于标准的、功能齐全的 Web 服务器。
  
• 更多地了解路由 JSON 事件的 Bayeux协议。
  
• “Servlet API 和 NIO: 最终组合在一起
  ”（developerWorks，2004 年 2 月）提供更多关于非阻塞 I/O 的信息。