大型Java Web系统选型问题探讨
接池快好几倍了。这不是说WebLogic性能不好，只不过weblogic要实现更多的功能，所以在单一的速度方面就会牺牲很多东西。
以我的经验来判断，使用tomcat5.5以上的版本，配置apr支持，进行必要的tuning，使用BEA JRockit JVM的话，在你们目前的刀片上面，支撑500个并发完全是可以做到的。结合你们目前20个刀片的硬件，那么达到1万并发是没问题的。当然这样做的前提是必须扔掉EJB，并置web层和业务层在同一个JVM内部。
接下来robbin还针对davexin对话题中的应用分别在tomcat和weblogic上的测试数据进行了分析：
引用：
2。1台weblogic10 Express（相当于1台tomcat，用于发布jsp应用）加1台weblogic10（发布ejb应用），能支持1000个并发用户
4。1台tomcat4.1加1台weblogic8，只能支持350个并发用户，tomcat就连结超时，说明此种结构瓶颈在tomcat。
这说明瓶颈还不在EJB远程调用上，但是问题已经逐渐清楚了。为什么weblogic充当web容器发起远程EJB调用的时候可以支撑1000个并发，但是tomcat只能到350个？只有两个可能的原因：
你的tomcat没有配置好，严重影响了性能表现
tomcat和weblogic之间的接口出了问题
接着springside项目发起者江南白衣也提出了一个总体的优化指导：
1.基础配置优化
tomcat 6？ tomcat参数调优?
JRockit JVM? JVM参数调优？
Apache+Squid 处理静态内容？
2.业务层优化
部分功能本地化，而不调remote session bean?
异步提交操作,JMS？
cache热点数据？
3.展示层优化
动态页面发布为静态页面？
Cache部分动态页面内容？
davexin在调整了Tomcat配置后应验了robbin对tomcat配置问题的质疑，davexin这样描述经过配置优化以后的测试结果：
经过测试，并发人数是可以达到像robbin所说的一样，能够在600人左右，如果压到并发700人，就有15%左右的失败，虽然在调整上面参数之后，并发人数上去了，但是在同样的时间内所完成的事务数量下降了10%左右，并且响应时间延迟了1秒左右，但从整体上来说，牺牲一点事务吞吐量和响应时间，并发人数能够提高500，觉得还是值得的。
至此这个话题有了一个比较好的结果。这个话题并非完全针对一个具体的项目才有意义，更重要的是在分析和讨论问题的过程中网友们解决问题的思路，尤其是cauherk、robbin、江南白衣等几位网友提出的意见可以让广大Java Web项目开发者了解到中、大型项目所需要考虑的架构和部署所需要考虑的关键问题，也消除了很多人对轻量Servlet容器与EJB容器性能的一些误解。
以我的经验来判断，使用tomcat5.5以上的版本，配置apr支持，进行必要的tuning，使用BEA JRockit JVM的话，在你们目前的刀片上面，支撑500个并发完全是可以做到的。结合你们目前20个刀片的硬件，那么达到1万并发是没问题的。当然这样做的前提是必须扔掉EJB，并置web层和业务层在同一个JVM内部。
接下来robbin还针对davexin对话题中的应用分别在tomcat和weblogic上的测试数据进行了分析：
引用：
2。1台weblogic10 Express（相当于1台tomcat，用于发布jsp应用）加1台weblogic10（发布ejb应用），能支持1000个并发用户
4。1台tomcat4.1加1台weblogic8，只能支持350个并发用户，tomcat就连结超时，说明此种结构瓶颈在tomcat。
这说明瓶颈还不在EJB远程调用上，但是问题已经逐渐清楚了。为什么weblogic充当web容器发起远程EJB调用的时候可以支撑1000个并发，但是tomcat只能到350个？只有两个可能的原因：
你的tomcat没有配置好，严重影响了性能表现
tomcat和weblogic之间的接口出了问题
接着springside项目发起者江南白衣也提出了一个总体的优化指导：
1.基础配置优化
tomcat 6？ tomcat参数调优?
JRockit JVM? JVM参数调优？
Apache+Squid 处理静态内容？
2.业务层优化
部分功能本地化，而不调remote session bean?
异步提交操作,JMS？
cache热点数据？
3.展示层优化
动态页面发布为静态页面？
Cache部分动态页面内容？
davexin在调整了Tomcat配置后应验了robbin对tomcat配置问题的质疑，davexin这样描述经过配置优化以后的测试结果：
经过测试，并发人数是可以达到像robbin所说的一样，能够在600人左右，如果压到并发700人，就有15%左右的失败，虽然在调整上面参数之后，并发人数上去了，但是在同样的时间内所完成的事务数量下降了10%左右，并且响应时间延迟了1秒左右，但从整体上来说，牺牲一点事务吞吐量和响应时间，并发人数能够提高500，觉得还是值得的。
至此这个话题有了一个比较好的结果。这个话题并非完全针对一个具体的项目才有意义，更重要的是在分析和讨论问题的过程中网友们解决问题的思路，尤其是cauherk、robbin、江南白衣等几位网友提出的意见可以让广大Java Web项目开发者了解到中、大型项目所需要考虑的架构和部署所需要考虑的关键问题，也消除了很多人对轻量Servlet容器与EJB容器性能的一些误解。