浏览 12503 次
|
锁定老帖子 主题：关于B/S结构的效率的讨论
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2003-11-25
jlinux 写道:
引用 典型的把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的效率展开讨论. 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2003-11-25
如果我们使用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这边处理), 我们可以运用一种write through cache(好象是这个名字)的方式来同步数据, 也就是说, 当数据从App server往DB server中写数据时, 同时也在App server的cache中写相应的数据, 这样省去了从DB数据库中刷新cache数据这一步, 而把这些处理放在App server中, 也应算是一种平衡的理论方法吧. |
| 返回顶楼 | |
|
发表时间：2003-11-25
jlinux 写道 关于B/S结构下的数据库还有一个问题就是java开发人员不注意SQL语句,而且不管自己的SQL语句效率如何,只要数据正确,这是一个大问题,在我原来(我现在失业了^_^)项目小组中,就有这样的人, 因为一个SQL语句导致整个系统崩溃也是发生过的. 所以建议所有的java程序员补一补数据库的知识, 特别是数据库设计和SQL语句.
这确实是一个问题，现在很多 Java 程序员对于低层的一些技术尤其是数据库技术了解甚少。甚至有人认为有了 CMP 或者 Hibernate 就可以不用在数据库上下工夫了，这完全是一个误解。 当数据库访问效率真正成为系统瓶颈的时候，我常常束手无策。但是我并不担心，我的同事对数据库实现技术非常了解，他总能给我提出合理的建议。 国外的软件公司分工很明确，除了 PM 和系统架构师外，每个人只负责系统的一小部分，因此他可以精益求精，把工作做到细处。但是国内的软件公司由于规模限制和成本上的考虑，不可能分得这样清楚。通常的以对象建模为主的系统往往把数据库性能的提高作为一个局部问题放在开发的后期来做（没必要再搞一次对象建模 vs. 数据建模的主义之争了吧？）。一个比较稳妥的解决方案是采用成熟的框架，并且自己摸索出一套行之有效的解决性能问题的方法（可以称为设计模式），把这些经验写进编程规范，大家共同遵守。这样程序员就不必花费过多的精力去研究数据库优化了。其实在一个项目中有一个数据库方面的专家就足够了。编程规范的作用就是让大家在开发早期就能预防的一些性能问题的出现，在开发快结束时再去解决这些问题往往意味着更多的修改和更高的成本。 软件质量分内部质量和外部质量，外部质量包括系统的界面、使用方便性、性能等等，内部质量包括系统架构的合理性，维护的方便等等。客户往往只凭外部质量来判断系统的优劣。数据库专家就是解决性能这个主要的外部质量问题的。所以设计师在做设计的过程中应该多听取数据库专家的意见。业务专家、OO 专家、数据库专家、算法专家在一个项目中彼此尊重对方的专业，各得其所，才能共同建造出一个完美的系统。 |
| 返回顶楼 | |
|
发表时间：2003-11-25
dlee 写道 一个比较稳妥的解决方案是采用成熟的框架，并且自己摸索出一套行之有效的解决性能问题的方法（可以称为设计模式），把这些经验写进编程规范，大家共同遵守。这样程序员就不必花费过多的精力去研究数据库优化了。其实在一个项目中有一个数据库方面的专家就足够了。编程规范的作用就是让大家在开发早期就能预防的一些性能问题的出现，在开发快结束时再去解决这些问题往往意味着更多的修改和更高的成本。
非常同意dlee的方法 我个人觉得项目开发的风险主要是两个大的部分,1为技术风险, 2为软件项目管理风险. 而如果一个公司或团队能够建立自己的一套成熟的框架, 一套行之有效的解决性能问题的方法, 并完善自己的编程规范和培训机制, 那么技术风险就慢慢被减弱了, 这样项目团队就可以集中精神处理软件项目管理的风险. 当然我觉得这个里面需要强调的一点(不是说其他的不重要, 只是这一点很容易被人忽略). 就是培训. 对于一个项目团队来说, 人员的稳定是很重要的, 但是难免会出现人员流失或者新增人员的情况, 如何让新人经快适应团队并且把对项目团队的影响降到最低, 这就需要培训. 很多项目组或公司, 没有任何成型的培训文档和计划, 几乎都是让新人去看代码看以前的文档, 新人几乎无法很快适应团队, 而且会带来挫折感,甚至给整个项目团队带来不稳定. |
| 返回顶楼 | |
|
发表时间：2003-11-26
我认为现在有了成熟的框架象Hibernate, 底层的大部分SQL由它来负责, 至于说到JDBC与Hibernate的效率, 两者之间的插入与查询差别不是很大, 批量删除与批量更新有一定的差距, 所以如果对速度要求严格的话, 可以把相应的一部分批量删除与批量更新SQL写在store procedure中, 但考虑到同步问题, 最好不要同时运行Hibernate和store procedure. 在store procedure这部分的sql是可以优化的, 除了sql优化以外, 我更看重数据库本身的优化, 从表的合理设计, 比如适当的冗余, 还有调整SGA的大小, 为了解决I/O争用, 把日志文件和数据库文件放在不同的硬盘, 或使用RAID方式, 有时如果我们并不在乎事务回滚, 可以关闭回滚日志的读写. 把经常要查询的数据簇在一起, 建立正确的索引使其与相关的sql相对应 or vice versa.
总之, 这些优化工作可以由DBA来做, store procedure也不一定要由程序员来写, java程序员只专注业务流程, 也没有什么不可以的,他们可以不理会sql的优化而把RDB当成OODB来操作,当然从职业生涯去说又是另一回事了. |
| 返回顶楼 | |
|
发表时间：2003-11-26
我完全同意 jlinux 的意见。软件开发最大的成本在于沟通上的成本。信息交流不畅所带来的风险是软件开发中最大的风险。如何改善软件开发过程中的交流？要从管理入手。传统制造业中常见的金字塔式管理结构人为地造成了很多信息交流的障碍。有活力的软件企业往往采用一种距阵式的扁平管理结构，最大限度地减少了层级，打破了人造的藩篱，促进了信息的沟通。
一个有活力的软件企业一定要创造一出种非常 open 的企业文化，鼓励大家畅所欲言。有些 PM 认为少说话多做事的程序员就是好程序员。我当然不喜欢只说话不做事的程序员（这样的程序员好象不多吧），但是我更不喜欢那种只会唯维喏喏，不求有功但求无过，没有思想的程序员。我不认为培养这样的程序员（某些人梦寐以求的软件蓝领）真的符合公司的利益。信息交流畅通、畅所欲言，就可以尽早地发现和规避风险（很多风险正是战斗在第一线的程序员才能最早发现的）。除了少量核心的技术机密，一个企业的知识不是属于某个个人的，应该是只要需要就可以自由获取。应该从管理上鼓励知识最大限度的共享，并且给那些共享知识的人以补偿（奖金、升职等等）。 这个话题谈下去就长了，现在已经跑题了。我们可以另开一个线索讨论知识管理的问题。 我建议一些软件公司的管理者最好把这两本书找来读一读： 《人月神话》，了解什么是软件开发的核心问题和次要问题。 《人件》，了解为什么要尊重人的个性和创造力，为什么一个软件企业必须是一个以人为本的企业。 |
| 返回顶楼 | |
|
发表时间：2003-11-26
呵呵, 好象扯到项目管理上了, PM的作用我认为在于发挥出团队成员不同的潜力, 就象划船, PM要清楚,哪些人适合放在左边划, 哪些人适合放在右边划, 怎样才能保证船上的每个人不出现瓶颈作业,我认为的真正PM应在项目开始到结束的时间一直是技术和管理的核心(没有过硬的技术, 首先不能服众, 尤其在国内), 也只有这样, 才能对整个工作量,工作进度有一个总体的正确的把握, 至于说到人员流动, 这里面涉及到的东西太多, 薪水, 工作环境, 员工对自已不同阶段的定位取向(如知识的渴求度), 企业文化可以发挥一个员工的潜力, 但人员的流动, 有时我认为是靠老板招人的运气(有点偏激).
|
| 返回顶楼 | |
|
发表时间：2003-11-26
^_^ 是有点跑题了， 不过没关系。其实dlee上面提到了企业文化的问题。
就我所知中国的很多中小软件开发企业很少能考虑到企业文化的建立上去， 出了他们本身实力的影响， 更多的要考虑生存， 另外一方面， 企业领导人的短视。 我刚离开的那家公司就是这样。 我去的时候刚成立， 所以我必须负责组织整个项目开发团队， 到上个月离开为止已经有15个编程人员了。在这之前我觉得我已经建立了一个大家已经相互了解的各方面都比较成熟团队， 如果稳定下来应该可以大有作为， 但是因为老板更多的想的是如何节省开支， 所以开发人员的工资都比较底， 而且对于员工， 他更多的考虑是如何去控制他而不是让他和公司一起发展。 他老是对我说的一句话是， 我们应该经常招人， 储备着， 开发人员就算走了也有顶上。 哎！我实在无话可说。 我现在离开了， 我组织起来的团队又走了4个人， 我想他们慢慢就会散掉的。 短视的领导不会去考虑什么企业文化的， 就算考虑了， 也没用， 因为作为文化的主体， 人都没有了。 |
| 返回顶楼 | |
|
发表时间：2003-11-26
dlee 写道 。业务专家、OO 专家、数据库专家、算法专家在一个项目中彼此尊重对方的专业，各得其所，才能共同建造出一个完美的系统。
这种情况听起来很美, 但实际项目中很难做到, 我上月听了Kent Beck在bonCon的一个关于XP的讲座, 他提到, 在项目设计中应该多一些general specialist, 因为项目设计中到处都是tradeoff, 相对来说一个general specialist做出来的tradeoff要比两个不同特长的专家讨论作出的tradeoff要好. 实际上想一想, 在做商业程序中, 我们用到的j2ee和数据库技术并不复杂, 大多数java guy是花时间去研究ejb, hibernate, offbiz, spring等, 而数据库 guy又去花时间研究oracle, mssql, mysql等, 其实不如光研究hibernate和oracle, 会更有用些. |
| 返回顶楼 | |
|
发表时间：2003-11-27
yyanghhong 写道 这种情况听起来很美, 但实际项目中很难做到, 我上月听了Kent Beck在bonCon的一个关于XP的讲座, 他提到, 在项目设计中应该多一些general specialist, 因为项目设计中到处都是tradeoff, 相对来说一个general specialist做出来的tradeoff要比两个不同特长的专家讨论作出的tradeoff要好.
实际上想一想, 在做商业程序中, 我们用到的j2ee和数据库技术并不复杂, 大多数java guy是花时间去研究ejb, hibernate, offbiz, spring等, 而数据库 guy又去花时间研究oracle, mssql, mysql等, 其实不如光研究hibernate和oracle, 会更有用些. 对的，我们都应该争取做到一专多能，甚至同时成为几个领域的专家，这样才能拓宽自己职业生涯的发展道路。 |
| 返回顶楼 | |
