关于ejb和javaBean的性能问题

如果系统的访问量很大,性能需求也很严格.项目让你来负责
你会采用何种架构?会不会使用ejb?
ejb的io会不会造成瓶颈?(lookup的)
使用javaBean加上一个好的连接池并且使用存储过程
效果会不会好一些?

请大家讨论讨论.我希望能够听到不同的声音

>>使用javaBean加上一个好的连接池并且使用存储过程效果会不会好一些?

性能会有很大的提高,如果是在单个JVM上面跑。


>>如果系统的访问量很大,性能需求也很严格.项目让你来负责你会采用何种架构?会不会使用ejb?

根据budget而定。


>>lookup的

只有第一次耗时。第二次开始几乎没有时间开销。

谢谢robbine大哥的回答.

现在ejb在j2ee体系中好像面临着一种很尴尬的局面?一般的系统使用ejb的好像都不太多吧?
项目预算不是问题,由于是一个非常重视性能(实时通信,电话服务的那种系统),对于反应速度要求非常严格.每个页面(前台的jsp)的切换不能超过2 s,知识库的查询也如此,同时连接数约为3000(持续不断,7*8方式)
现在有很多种备选方案,其中包括javabean,dao,ejb等数据库操作方式,但是我对这些东东的具体性能指标不是很清楚.(jdo暂时不作考虑..呵呵)
服务器的布置是用两个weblogic的服务器做成集群,所有的访问在同一个jvm中进行.

另外,对于lookup的问题robbine兄能否解释的清楚一些,第一次访问的时候会比较慢,以后就很快了?这是什么原因呢?

谢谢

不要为了使用ejb而使用ejb。Just a tool out there.

嗯,我非常同意您的观点.
所以我现在在这几个东西里面徘徊
从性能上面考虑我是不是该排除ejb?
我看了一些性能报告,也包括一些网友的讨论
涉及到大量数据和性能要求较高的项目好像都不赞成使用ejb
或者部分,小数量的修改使用ejb的比较多.
而使用了ejb的项目和系统往往使用sessionBean来进行大数量的访问
而bmp或cmp的entityBean只是对小数量的数据进行修改和插入.

这样一来和ejb的整个架构感觉有些异样,sessionBean访问数据库操
作好像是不被推荐的?entityBean的循环和频繁查询会大大降低性能?

>>对于反应速度要求非常严格.每个页面(前台的jsp)的切换不能超过2 s,知识库的查询也如此,同时连接数约为3000(持续不断,7*8方式)


噢,对实时性要求那么高的话,不但业务层,连Web层都需要优化了。要减少JSP Taglib的使用,简化整个架构的层次。

EJB的优势在于分布式调用,容器管理事务,以及在集群中的可扩展性。前两个大家都明白,最后一个的意思是可以突破JVM的性能瓶颈,把EJB扩展到多个JVM上进行集群。因为性能提高到一定程度,受JVM限制很难再上升了,如果能够在多个JVM上面集群,性能还可以近似线性上升。

你的应用我的个人的主张如下:

1、不采用EJB的方式
如果你们对EJB和WLS的集群操作不是那么精通,还是直接用Java Bean来的保险,好好进行优化,必要的情况下引入一些第三方的缓存软件,还是可以达到很高的性能的。另外我建议减少JSP Taglig的使用,这个东西会降低JSP页面的性能。

2、采用EJB的方式
如果精通WLS集群,那么可以采用 SLSB + DAO + JDBC的架构,如果硬件性能很好,例如2颗CPU,可以启动两个JVM做集群,这样性能也应该相当不错。

谢谢robbin的热心帮忙先.

你的建议主要是说:1.减少结构层次 2.使用缓存机制(slsb也相当于池的作用吧?)还有一点儿问题:

1.在您的建议中使用javaBean提到一个三方的缓存软件是指的哪些?
是具体的软件还是诸如CacheResultSet之类的api?
2.如果使用ejb的话建议使用slsb+DAO+JDBC的意思是说不使用entityBean
直接通过dao去访问数据库是吗?

硬件性能还不错,服务器级别的配置:每台服务器都是双cpu(2.2G的),数据库服务器通过光纤磁盘阵列存储.

1、指软件,有很多这类软件,例如Apache Turbine下的JCS子项目就是一个专门的对象缓存软件。

2、是的,我建议放弃Entity Bean。


硬件不错阿,可以采用WLS集群了。