设为首页 收藏本站
查看: 2061|回复: 0

[经验分享] 关于tomcat和jetty对比(不喜欢jetty的勿看)

[复制链接]

尚未签到

发表于 2018-12-2 10:54:22 | 显示全部楼层 |阅读模式
  首先转载下别人总结的文章
  相同点:
  1.      Tomcat和Jetty都是一种Servlet引擎,他们都支持标准的servlet规范和JavaEE的规范。
  不同点:
  1.      架构比较
  Jetty的架构比Tomcat的更为简单
  Jetty的架构是基于Handler来实现的,主要的扩展功能都可以用Handler来实现,扩展简单。
  Tomcat的架构是基于容器设计的,进行扩展是需要了解Tomcat的整体设计结构,不易扩展。
  2.      性能比较
  Jetty和Tomcat性能方面差异不大
  Jetty可以同时处理大量连接而且可以长时间保持连接,适合于web聊天应用等等。
  Jetty的架构简单,因此作为服务器,Jetty可以按需加载组件,减少不需要的组件,减少了服务器内存开销,从而提高服务器性能。
  Jetty默认采用NIO结束在处理I/O请求上更占优势,在处理静态资源时,性能较高
  Tomcat适合处理少数非常繁忙的链接,也就是说链接生命周期短的话,Tomcat的总体性能更高。
  Tomcat默认采用BIO处理I/O请求,在处理静态资源时,性能较差。
  3.      其它比较
  Jetty的应用更加快速,修改简单,对新的Servlet规范的支持较好。
  Tomcat目前应用比较广泛,对JavaEE和Servlet的支持更加全面,很多特性会直接集成进来。
  Google 选择 Jetty, 放弃 Tomcat
  转载:原文链接http://www.iteye.com/news/9918
  Google 应用系统引擎最初是以 Apache Tomcat 作为其 webserver/servlet 容器的,但最终将切换到 Jetty 上。 这个决定让许多开发人员都诧异的想问:为什么要做这样的改变?Tomcat 有什么问题吗? 我们获得的一次访问Webtide ——Jetty 背后的公司——里的这个团队的机会,得到了关于这个决定背后更详细的信息。
  记者: 为什么Google选择Jetty作为其应用系统的引擎,而不是 Tomcat 或其他的?
  Google选择Jetty的关键原因是它的体积和灵活性。 在云计算里,体积的因素是很重要,如果你运行几万个Jetty的实例(Google就是这样干的),每个server省1兆,那就会省10几个G的内存(或能够给其他应用提供更多的内存)。
  Jetty 被设计成了可插拔和可扩展的特性,这样Google就可以高度的自定义它。 他们在其中替换了他们自己的HTTP connector,Google认证,以及他们自己的session集群。也真是奇怪,这个特性对于云计算来说是非常出色的,但同时也让Jetty非常适合嵌入小的设备中,例如手机和机顶盒。
  记者: 是什么促使Jetty成为Java里出色的servlet容器?
  我们在开发Jetty时,并没有想着要把它开发成一个全功能的应用server(尽管它是的)。每一项功能都考虑了可插拔性,所以,如果你不需要他,你就可以不把它加载到内存里,把它从request 处理调用链中去掉。如果你不需要sessons,你可以把session处理器拿掉,这样你就不要浪费资源去来回寻找session cookie了。当你每秒钟都有出来上千个请求时,这些微小的查找动作的开销是非常的大的。
  我们也并没有想当然的企图通过设计就可以得到最优化的代码,我们是如同收集沙粒般,每次得到一些人告诉我们如何才能有好的JVMs优化和垃圾回收办法。这是真的,已经很小心的代码仍然能被优化,最后的效果就是避免创建新的对象。例如,我们在Jetty里使用并行处理技术,但我们并没有使用很多标准的并行处理数据结构,因为这需要创建太多的对象。所以,只是作为个例子,我们使用了双并行锁循环 arrays,而不是采用并行链式 lists,这样我们就能够在不创建对象的情况下,获得了非阻塞并行效果。
  记者: 是什么使Jetty成为开发人员的一个有用的server平台的(例如:testing)?
  Jetty 已经在一些流行框架中内置了,例如GWT,scala/lift,grails,Jruby等等,还有很多。如果你使用了这些技术,你就直接可以用Jetty了。 Jetty-maven 插件是另外一个非常优秀的开发工具,它能让web应用在不打包成war文件的情况下运行。源文件可以直接编辑,在不需要把它重新放进war文件的情况下获得测试结果。 Jetty嵌入式的特征让我们不再需要写通过写那些main方法、通过你的IDE,调试器或 profiler 来运行之类的无聊的事情。
  记者: Jetty在处理 client-server 请求时有什么独特的地方吗?
  Jetty 现在是一个第二代的异步处理server。 过去的两年里,我们让Jetty实现了处理异步请求的功能,这成了它核心架构的一部分。就像其他的支持异步serlets容器一样,我想,他们会发现这个东西并不是看起来的那么简单和容易。 我们的异步HTTP引擎被我们复用在了HTTP client 上,所以我们可以大量的降低request 和 responses 消耗。
  同时,就像我之前提到过的,我们的请求处理器是可扩展和可插拔的,这让web application可以被单独省略掉,或者是单独使用,或者是进一步扩展的application。
  记者: 有没有其他Jetty使用的案例,大的或小的?

  使用Jetty的公司有像Zimbra/Yahoo,这意味着Jetty正作为web mail 服务器,为百万级的用户提供服务。 Eclipse>  记者: Jetty的将来或蓝图是怎样的?
  Jetty 最近的计划是发布 7.0.0 版本,这将会完全的迁移到eclipse foundation 下。 Jetty 7 将会支持很多 servlet 3.0 的特征,但是并不会使用新的API 和 不会依赖Java 1.6 。 Jetty 7后,很快我们会发布Jetty 8,这将会完全支持 servlet 3.0 和 Java 1.6,Jetty 会继续的创新 和跟踪各种web 2.0 里的其他的新成果。 我们现在已经能支持 Firefox 3.5 里的跨域Ajax功能,我们可以在cometd版本里使用这个。 我们很快就会增加对 WebSocket 和 BWTP 的支持。 对 Google wave 以及相关协议的支持的问题已经优先排到了我们的议事日程上了。
  记者: Google/Jetty 还有其他的计划吗?
  Google有他们自己下棋的棋局,我们并不清楚。 我们在JavaOne大会上曾经和App Engine开发者们有个简单的对话,我们愿意听他们任何的反馈和意见,用来改进Jetty的可嵌入性和可扩展性。
  下面的跟Webtide团队的讨论中,我们询问了SpringSource 从Jetty转换到Tomcat的事情。
  记者: 你们如何看待 SpringSource 把 Grails 从本来作为缺省容器的Jetty换成了Tomcat的事情?
  原因是grails开发的领导感觉使用Tomcat能从内部的Tomcat开发人员哪里获得更好的”服务“。我猜测,他们把Grails的用户驱赶到某一个平台,以让SpringSource能更好的销售他们的技术支持服务。几年前我们看到了相同的事情,JBoss 雇佣了一下tomcat开发人员后把Jetty提出成了Tomcat,并最终和Mort Bay达成了商业合同。 很遗憾,这些商业协议对技术选择有如此大的影响,当相同的是,一些基础结构的工程也正聚集到也application server 为中心的队伍里来。
  rails将会继续同时支持对Jetty和Tomcat的集成,但会改成Tomcat为缺省服务。
  这看起来是 SpringSource使用/攀附 Tomcat 的一个特别合适的论断。
  以下是个人一些浅薄看法,毕竟不是开发
  之前用jetty,作为一个ops 来讲,简直不要太爽,maven 或者grandle 构建成jar 包直接java -jar 运行
  环境无非就是java 6-8,随便你配置,那么问题来了,tomcat 也可以啊,我想说大不大?
  费劲不?开发天天找你问你怎么改配置 烦不烦?
  而且这么做有个非常好的好处就是,为容器化,打下非常好的基础,因为只有一个jar包和N个配置文件
  那么在生成镜像的时候,会大幅度减少容器体积本身的大小
  既然说道体积了,上文说,说内存使用,jetty 运行的时候,一般用个1g 运行足以,除非代码写的特别臃肿,这样,和tomcat 一对比,相对与我们ops 而言,意味着,有大量的空余内存啊,内存啊,那是鲜血班的存在,我曾经在一台4核8G的机上跑了12个jetty,爽不爽,了不起就是两台多挂几个负载,这维护成本非常的低,而且无脑,原则就是:人,能少碰机器,尽量别犯贱
  简单说:其实两者对性能的差异并不是很大,但是!但是!应用场景非常的不同,具体看上文,我就举一个例子,在一个需要长连接又要高连接的情况下,必然jetty 然后现实中,这个场景非常的多,毕竟不是人人都是多年的经验的架构师,对吧,不然google 会抛弃tomcat了


运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-642305-1-1.html 上篇帖子: tomcat并发数优化maxThreads、acceptCount(最大线程数、最大排队数) 下篇帖子: 16.4 配置Tomcat监听80端口16.5
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表