关于B/S结构的效率, 一些看法.Re: 谁偷走了我的ejb？

>>另一公司因为使用jsp+javabeans 两层结构，使用jdbc直连数据库（相
>>同水平下，理论上速度应比使用ejb更快），慢的导致用户不满，已经
>>被中途踢掉了。

典型的把B/S结构做成了C/S结构, 而且比真真的C/S结构效率低下是肯定的.

B/S结构怎么能和C/S结构比较呢??? 让我们来比较这样作两者的结构把

这种B/S结构其实就是Browers--->Java(JSP+Java Bean+JDBC)--->DB的结构, 而其中肯定没有加诸如缓存等等增强性能的设计. 在这种情况下其实和C/S结构通过ODBC或者其他直接访问数据库是没有任何区别的.

在用B/S结构做过几个中型企业信息话项目(白天平均在线人数80左右),刚开始我们也是这样设计的, 效率的确成问题, 还好因为我的设计中使用了DAO和VO模式, 所以在第一个项目的后期在DAO统一加入了缓存, 这才提高了大部分的效率, 让整个项目通过了验收. 如果这个项目没有使用DAO/VO模式, 估计肯定死掉.

通过这几个项目对于B/S结构的效率, 我有一些体会
1.提高效率的基础 (没有基础, 谈不上优化效率, 只不过是小打小闹)
首先是技术构架要合理, 如果技术构架不合理, 那么就很难找到提高效率的地方和方式. 至于上面那种结构,几乎没有技术构架可言.如果技术构架不合理, 不管你如何优化自己的程序都是不可能的大幅度的提高效率的.
其次是数据库设计, 这是另外一个重要的方面, 在数据库设计需要考虑本身的效率和功能实现时的效率, 而且希望能以简单为主,比如说表之间的关联关系等等. 大家都应该知道同样的数据量下, 5个表的关联查询比3个表的要慢(只是一个例子). 在我开发的一个项目中, 给遇见过因为数据库设计不好导致效率低下, 不论我怎么优化程序都无济于事, 随后重新设计了数据库结构, 简化了设计. 在其中我们还有一个很极端的做法, 一些常用数据时重复的, 比如说一个表关联了用户表, 那么在这张表里出了有ID字段, 还有用户姓名的字段.
关于B/S结构下的数据库还有一个问题就是java开发人员不注意SQL语句,而且不管自己的SQL语句效率如何,只要数据正确,这是一个大问题,在我原来(我现在失业了^_^)项目小组中,就有这样的人, 因为一个SQL语句导致整个系统崩溃也是发生过的. 所以建议所有的java程序员补一补数据库的知识, 特别是数据库设计和SQL语句.
如果说上面还不能解决问题, 那么就必须考虑对数据库进行专门的优化或者数据库集群.
最后是程序员个人的编程能力.

2.提高B/S结构效率的总体方向
最主要的方向是平衡 App Server和DB Server的运行压力.
不知道有多少B/S结构在开始的时候比较过App Server和DB Server占用的系统资源, 可以试着把两者分开放到两个服务其上, 在上面提到的jsp+javabeans 两层结构中, 你肯定可以发现, App Server其实很轻闲, 而DB Server却很忙. 当然如果在这种结构下,如果反问次数不多, 却发现App Server系统资源占用率很高的话, 哪不用说, 肯定是系统结构不合理或者就是程序效率低下.
我作过这个比较, 在大量人员访问的情况下, 一般DB Server几乎满负荷运转, 而App Server去没有使用太多的系统资源.
所以如何平衡两者之间, 真真的把App Server利用起来是主要方向, 这样才能体现出App Server的优势.

在平衡了两者之间的运行压力以后, 如果还出现了大的效率问题, 那么只能使用提高硬件, 使用集群等等方式来提高效率了.

3.很好利用App Server的几种方法(以为实践的java技术有限,所以只能提出这几种, 希望各位高手能在提供一些)
(Connection pool等等常用的就不提了)
a. 缓存, 这是必不可少的, 把一些常用的数据从数据库中提取出来, 然后放在缓存中,这样可以减少访问数据库的次数, 加快读取速度. 我在具体实践是使用的是DAO模式和Hibernate, 使用hibernate的缓存机制对常用单条记录进行缓存, 使用jcs, 自己写程序, 对常用的数据列表(比如人员列表)作缓存
b. 静态页面, 在实际工作中, 有些数据长时间是不会发生改变, 这种情况下我就会考虑把这些数据存储为静态页面.本来是打算存储为XML文件的, 但是一直没有时间作
c. JMS 把一些同步处理改为异步处理, 加快反应速度, 把一些处理放到App Server空闲时来运行.


关于EJB, 在使用hibernate以后我基本上不再使用EJB, 因为不管是对开发人员的培训和高效的使用我都没有把握. 因为我自己对ejb就不是很精通, 至于它好与不好, 我没有太大的感觉. 也不想去讨论.


通过我自己的一些总结,希望大家能就如果增强B/S的效率展开讨论.

如果我们使用Hibernate, 可以利用Hibernate本身的一些事务处理方法, 例如: version/timestamp, 这样, 一些在以前必须通过在数据库端进行的事务处理, 如各种不同隔离级别的锁等机制, 现在可以通过使用Hibernate的version检查处理, 只是到了真正要提交到数据库的时候才使用数据库锁, 显然, 这样把一部分工作放在application/Hibernate这边可以减轻数据库在事务处理上的压力. 而且可以很好的支持长事务,因为长事务可以在JVM中做,丝毫不影响其它事务的处理,支持高并发环境, 只是如果更新较多的话, 可能事务的提交的成功率会下降.

<<最主要的方向是平衡 App Server和DB Server的运行压力
我觉得其实DB server, 象Oracle已经做了许多工作, 例如为了减少I/O,操做在内存中先处理, 并且也是先写在log中, 等需要时一起发送到数据库中. 如果App server与DB server不在同一机器上,减少网路传输数据的时间也是要着重考虑的. App server本身提供事务,安全,资源管理(连接池,对象池)等服务,优化和平衡也只能从这几方面考虑.除了上面的贴子可以优化事务方面外,我觉得在楼顶提到的架构上也很难在App server上做文章了. 如果把DB server上的一些功能放在App server上,把经常要操作的数据放在app server上,相当于把一个小型数据库放在app server这边,在一定的时间同步一下两边的数据,也许也是一种平衡的办法吧.我只是这样想想而已.

另外想到一点, 可以在cache上做文章.
一般cache操作是这样的,当从DB中取数据时, 把取到的数据先放在cache中,然后送到客户端, 以后如果cache满时, 运用LRU算法去掉暂时不用的cache数据,或timeout后,从DB数据库中刷新cache数据(这一步我觉得可以不用这样做而改在App server这边处理), 我们可以运用一种双向cache的方式来同步数据, 也就是说, 当数据从App server往DB server中写数据时, 同时也在App server的cache中写相应的数据, 这样省去了从DB数据库中刷新cache数据这一步, 而把这些处理放在App server中, 也应算是一种平衡的理论方法吧.

在实际我们做项目的时候, 对DB Server做过一下优化(我们用的Sybase的数据库)
环境为IBM小型机(忘了型号了)+Sybase 12.9数据库
就Sybase而言, 我们对其打了一个补丁, 这样起可以同时建立多个临时库.
因为在其中的一个数据库为标准化数据,用户数据和权限的数据库,几乎公司所有的系统(超过5个)都会去访问这个数据库, 所以我们把这个数据库全部放到了内存中, 以增加其的访问速度.

所以就bruce说的cache而言, 数据库端这样作我想已经可以.

至于bruce说的App Server端的cache, 我现在就是用Hibernate去处理的, 而且我觉得没有必要把数据库端的数据映射过来.


为什么JSP+JAVABean+JDBC就是CS结构呢
BS概念刚出来时还没有J2EE和.net
你所指的是不是三层或多层结构的意思?
缓存机制是独立实现的，C/S可以实现缓存
JSP+JAVABean+JDBC也可以实现缓存
另外解释一下，我所说的JavaBean不是教科书上的JavaBean
就是一些类