Jetty vs Tomcat:对比分析
原文:https://www.webtide.com/choose/jetty.jsp
颜色注释参考于:http://www.slideshare.net/noriaki/jetty-vs-tomcat
译者注:08年的文章,这个过程中Tomcat和Jetty都有了更多的发展,本文只做历史参考,不代表现在两者的对比尚如此。
1. 介绍
Jetty和Tomcat经常被称为直接的竞争对手。本文将从技术和非技术两个方面对这两个开源servlet容器进行简要的比较分析。
2. 技术比较
2.1. 架构(Architecture)
从浅层次的表面看来,Tomcat和Jetty颇为相似:它们同样是提供servlet 2.5规范实现的Java应用服务器,并可选额外的大量JEE特性。
然而,仔细观察下,两个服务器的架构差异很大,主要地它们在历史上便有着不同的关注点:
Tomcat是首要的应用服务器(first and foremost an application server)。它默认的存在形式是作为安排在操作系统的一个应用软件,在其内可以安装web应用程序。Tomcat亦可以被剥离,作为嵌入于或搭建于一个完整的JEE服务器上,不过这两种方式实践起来较为困难。Jetty是首要的提供HTTP和servlet服务的一套软件组件(first andforemost a set of software components that offer HTTP and servlet services)。Jetty可作为一个独立的应用服务器被调用和被安装于操作系统中,或者它可简单地嵌入于一个应用程序或框架,作为一个HTTP组件,作为一个简单的servlet引擎(simple servlet engine),作为一个功能丰富的servlet引擎(a feature rich servletengine)或作为完整的JEE环境的一部分。
灵活的基于组件的架构使Jetty可灵活地进行部署并整合于各种类型的场景中:
l 从移动手机到由重量级服务器(iron servers)组成的大型集群
l 在软件框架和工具中:如OSGi Equinox, OSGi Felix, Spring, Plexus, Cocoon, Tapestry, Maven,Continuum, Fisheye, Grails, JRuby, Xbean, 等等。
l 在JEE应用服务器中:Geronimo, Jboss,Sybase EAServer, JOnAS 和 Glassfish
l 嵌入于来自IBM,惠普HP,思科Cisco,BEA,雅虎Yahoo和Eclipse 的 应用程序,产品 和服务中。(详见http://docs.codehaus.org/display/JETTY/Jetty+Powered)
l 作为增强型服务的基础,这些服务如SIP(www.cipango.org),Ajax JMS(www.activemq.org),异步SOA(Asynchronous SOA)服务(Apache Camel)
l As the basis for enhanced services such a SIP (www.cipango.org), Ajax JMS (www.activemq.org), Asynchronous SOA services (Apache Camel)
随着servlet规范继续发展和增加额外的特性(如注解[annotations],自动化web服务[automatic web services],等),标准servlet服务器的开销在增大。虽然Jetty将一如既往地支持标准的服务形式(standardincarnation),其模块化的方式可进行有针对性的部署,使其只使用恰好足够的服务,而不会添加额外的复杂的、效率低下的或出于安全考虑的等不需使用的特性。
2.2. 性能
Jetty和Tomcat都提供良好的每秒请求处理的性能表现,同时对于任一重要的web应用,两者将成为瓶颈的因素是有很大的差异。
我们很难提供评测的一般基准,web负载的描述极大地受相应的实际应用的影响,而且对于一个特定应用的基准管理我们没有代替方案(General benchmarks are difficult toprovide and web load profiles are greatly influenced by the actual applicationand there is no substitute for specific application benchmarking.)。然而,我们可以做一些一般性的观测:
l 在仅保持极少数的忙连接(few very busy connections)的情况下,Tomcat往往会有略好些的性能表现。在请求延迟上它有微弱的优势,这种优势在大量请求/响应消息在少量的无明显空闲时间的连接上传送时尤为明显。
l 在维护大量有明显空闲时间的连接时,Jetty往往有着更好的可伸缩性,而这正符合大部分网站的实际场景。Jetty的小内存占用(small memory footprint)和预先的NIO网络接口对象(Advance NIO[NetworkInterface Object])使用使得每单元可用的内存可向大量的用户进行服务。而且,更小的内存占用意味着更少的内存和CPU缓存被serlvet容器所使用,如此更多的缓存可用于加速重要(non-trivial)应用的执行。
l 由于Jetty可使用结合NIO的预内存映射文件缓冲器将写操作聚集写操作,并指示操作系统以DMA最大速传输这些文件内容,而不用经过用户内存或JVM,所以Jetty还在静态内容(static content)服务上有些更好的性能表现。
2.3. 特性
Jetty和Tomcat都实现了serlvet2.5规范的核心标准内容,它们都提供一系列企业级应用所需的特性,如JNDI,JTA,JMS,邮件服务,等。Tomcat有一种简单的向完整的JEE如向Jboss和Geronimo迁移的方案;而Jetty亦有类似的简单迁移方案,同时支持的环境更多,如Geronimo, JBoss, JOnAS, Sybase EAServer and, 而且在一定程度亦支持 Glassfish
在最近18个月中,对web2.0特性,尤其是Ajax Push和Comet,的关注有所增长。从serlvet模型,Jetty在支持web2.0用例上已经处于领导地位,同时在向制定serlvet3.0规范的JSR315的一个提议中,网站已经将Jetty接入形式化。该提议很可能被接受成为提供web2.0所需的异步servlet的标准方案。相比较,Tomcat项目在接受web2.0用例上较为缓慢,不过现在它提供一种异步IOAPI,以满足其需求。然而,这种方法并不来自于servlet模型,所以并不能使用标准的框架(JSP, Struts,等)和技术。
3. 非技术比较
3.1. 市场占用率
选择市场领导者经常被用作重要的选择标准。虽然市场占有率经常是一个技术实力的标示,但经常许多非技术或历史的原因亦可能影响这个选择的标准——市场占有率——的高低,特别在受标准化严重影响的市场。
据Netcraft服务器调查报告显示,曾主导市场份额的Tomcat的市场占有率正在不断下降,而Jetty的市场占有率在近18个月中一直稳定地增长,其现占有率已经到达了Tomcat市场占有率的80%了。
Netcraft(http://www.netcraft.com)报告,调查仅仅是测量安装量的部分,因为许多服务器可能关闭了服务器识别,或者隐藏在负载均衡器(load balancers)或其他web服务器如apache后。如果考虑已安装基础(installed base),如此Jetty在大量框架和工具上的使用(如3.3版之后的Eclipse IDE)将给予Jetty数以百万计的常规使用基础。(If installedbase is to be considered, then Jetty's use in many frameworks and tools (e.g.in the Eclipse IDE from 3.3 onwards) would give Jetty a regular usage basis inthe millions.)
3.2. 参考实现
Tomcat曾经是serlvet2.4的参考实现,因此过去往往在此基础上选择了Tomcat。从版本2.5之后,Tomcat不再是serlvet参考实现。太阳微电子公司(Sun Microsystems)把Tomcat服务器放在一边而开发了Glassfish,以作为serlvet2.5和serlvet3.0,同时亦是JSP2.1之后的参考实现。
相反,Jetty紧密地关注规范化发展,同时忠实地实现之。Jetty开发者亦活跃于制定serlvet2.5的JSR-154和现在制定serlvet3.0的JSP-315中。因此,Jetty不仅仅跟随了serlvet规范化的发展,也有能力影响规范的持续改进以及预知即将而来的改变。
3.3. 开发社区
Jetty拥有着一个稳定地开发团队和过程,而且一直如此持续着超过十年。从1995年(当时还是用着java 0.9)开始,Jetty一直由相同的核心团队开发,同时一直由Mort Bay Consulting公司,现在是Webtide LLC和MortBay的合伙关系支持。这个项目存在于能独立思索(independently mined)的codehaus.org项目库中。这个活跃的Jetty开发者团队是一个中等规模,拥有健康、友好、协作等良好特性的团队。同时,由Jetty发展的扩展社区与许多其他开源项目有些紧密的协作,这些开源项目比如Maven,ActiveMQ,Spring,Eclipse,JBoss,Geronimo,等。
相反,Tomcat却拥有一个不幸运的历史,原因在于它的开发社区是破碎的,它的发展历程更多是出于革命而不是协作或创新。从版本3到4,4到5,5到5.5,5.5到6的Tomcat版本演进通常是社区分裂或核心成员离开项目组所引发的结果。在以下事件中,Tomcat项目的治理和发展问题达到顶峰:
l 失去了参考实现的地位
l 项目分支到Glassfish
l 项目从Commit&Review转变成Review&Commit。
即将来临的Servlet3.0将需要对所有serlvet服务器的关键性增强。有着一致和谐的,有经验的和经考验的开发团队和过程,将成为平滑地过渡到新规范以及其支持的服务和特性的关键因素。
4. 总结
Tomcat是一个合理的优质的Java应用服务器(The Tomcat project is areasonable quality Java application server),它有着知名的品牌和巨大的用户基础。在以之为主角时,它能很好地满足需求。然而,它的确缺少了作为一个软件组件的灵活性和作为一个项目和社区的适应变化需求和使用创新(adapt to changing requirements and new innovativeusage)的能力。
Jetty项目/团队则有着对创新和不断变化的需求作出反应的态度和历史。正便成就了一个拥有良好架构的软件平台,它能整合和部署在几乎任何一个环境,而且由一个拥有庞大的,健康成长的社区支持着。