网站运营
位置:首页>> 网站运营>> 大型Java Web系统服务器选型问题探讨(3)

大型Java Web系统服务器选型问题探讨(3)

 来源:asp之家 发布时间:2010-05-02 18:28:00 

标签:系统,服务器,java服务器

我们的压力不在数据库层,在web层和F5。 当高峰的时候 ,F5也被点死了,就是每秒点击超过30万,web动态部分根本承受不了。根据我们程序记录,20台web最多承受5000个并发,如果再多,tomcat就不响应了。就像死了一样。

这个回复让接下来的讨论都集中于Web容器的性能优化,但是JavaEye站长robbin发表了自己的意见,将话题引回了这个项目的架构本身:

performance tuning最重要的就是定位瓶颈在哪里,以及瓶颈是怎么产生的。

我的推测是瓶颈还是出在EJB远程方法调用上!

tomcat上面的java应用要通过EJB远程方法调用,来访问weblogic上面的无状态SessionBean,这样的远程方法调用一般都在100ms~500ms级别,或者更多。而如果没有远程方法调用,即使大量采用spring的动态反射,一次完整的web请求处理在本地JVM内部的完成时间一般也不过20ms而已。一次web请求需要过长的执行时间,就会导致servlet线程被占用更多的时间,从而无法及时响应更多的后续请求。

如果这个推测是成立的话,那么我的建议就是既然你没有用到分布式事务,那么就干脆去掉EJB。weblogic也可以全部撤掉,业务层使用spring取代EJB,不要搞分布式架构,在每个tomcat实例上面部署一个完整的分层结构。

另外在高并 * 况下,apache处理静态资源也很耗内存和CPU,可以考虑用轻量级web server如lighttpd/litespeed/nginx取代之。

robbin的推断得到了网友们的支持,davexin也认同robbin的看法,但是他解释说公司认为放弃SLSB存在风险,所以公司倾向于通过将Tomcat替换为Weblogic Server 10来提升系统的用户支撑能力。robbin则马上批评了这种做法:

坦白说我还从来没有听说过大规模互联网应用使用EJB的先例。为什么大规模互联网应用不能用EJB,其实就是因为EJB性能太差,用了EJB几乎必然出现性能障碍。

web容器的性能说到底无非就是Servlet线程调度能力而已,Tomcat不像WebLogic那样附加n多管理功能,跑得快很正常。对比测试一下WebLogic的数据库连接池和C3P0连接池的性能也会发现类似的结论,C3P0可要比WebLogic的连接池快好几倍了。这不是说WebLogic性能不好,只不过weblogic要实现更多的功能,所以在单一的速度方面就会牺牲很多东西。

以我的经验来判断,使用tomcat5.5以上的版本,配置apr支持,进行必要的tuning,使用BEA JRockit JVM的话,在你们目前的刀片上面,支撑500个并发完全是可以做到的。结合你们目前20个刀片的硬件,那么达到1万并发是没问题的。当然这样做的前提是必须扔掉EJB,并置web层和业务层在同一个JVM内部。

0
投稿

猜你喜欢

手机版 网站运营 asp之家 www.aspxhome.com