|
这个主题共有 14 回复 ／ 1 页 [
]
|
|
|
|
|
|
关于系统性能的一个问题
|
发表: 2005年09月04日 15:16
|
回复
|
|
偶们公司的软件采用J2EE开发，底层数据的处理是Hibernate，业务处理用EJB，一些可重用的组件写放在BO层介于EJB和Hibernate之间。前台页面的展现采用第三方的一个工具，Extra.现在产品开发已经完成，业务处理虽有一些问题，但问题不大。可性能上却值得怀疑。因为我们的页面展现和后台的处理是独立的。但Extra的速度实在在慢了，一是因为这种Taglib要生成大量javascript代码，好多都是全局变量，造成数据流量太大；另一方面由于它在查询数据时要把所有的数据都载入内存，开销极大。偶们的系统包括系统控制，物流，生产，财务，人事，分销，CRM等等,非常庞大。在运行的时候感觉后台的速度也可以，但前台的速度实在太慢了，一个下拉列表慢的时候甚至要十几秒钟，这样要录入几十个字段的数据非疯了不可。
目前想重整架构，想在前台页面这一部分动动手脚。因为Extra在开发的速度方面快得让人羡慕，有点难以割舍。但性能的要求使我们不得不考虑新的方式。请问大家在页面展现方面有没有一些好的方式。请不吝赐教，小弟初来咋到，在这里谢过了！
|
|
|
|
|
|
Re: 关于系统性能的一个问题
|
发表: 2005年09月04日 16:45
|
回复
|
|
唉，你这个问题真是一个典型案例啊，这个案例教训说明了下面几个问题：
1. 项目开始之初，架构选择是设计和性能等因素的综合平衡考虑，特别是在选择现有框架时，对其需要从几个方面进行考核：
Scalability Transparency Extendable Performance Availability。
2.注意这些框架选择之后，它们在搭配组合方面是否有一些陷阱，如性能陷阱等。
3. 其实对于实际应用来说，因为有这些现成框架帮助我们实现了设计目标，所以我们的重点需要放在性能上，说白了，是要在内存状态和数据库持久化状态之间做一个平衡，比如，帖子的浏览数，一般都习惯使用数据库一个字段增1，但是这是个性能尖刀，访问量大时会最先冲击系统稳定性，所以，应该使用内存状态变量保存浏览数，定期写入数据库即可。
4.一个项目需要一个性能架构考虑，性能考虑和其他考量是不同的，是另外一条方向，要有专门人员深入设计，这点一般系统最容易忽视。性能一旦出现问题，就象内存泄漏一样，不是某个环节的问题，而是整体架构到详细设计编码等各个环节问题。
以你这个案例，性能问题你认为是查询时将所有数据载入内存所导致，但是这种做法不是某个框架的错，因为它的优化目标不是在这里；这也说明引入一个框架能够全面知道其优缺点，特别是性能勿视点很重要，而目前这是大部分框架的一个通病。
当然，这里免不了我介绍我设计的开源框架Jdon Framework，它有两个快速开发/快速运行的特点：1.CRUD（增删改查） 2.批量查询，这些都可以从相关演示和测试中了解。
你可以使用jmeter作为模拟不同网址(不同session)客户端对你的系统进行测试，包括引入性能提升框架如Jdon框架的前后对比。
|
|
|
|
|
|
Re: 关于系统性能的一个问题
|
发表: 2005年09月05日 10:47
|
回复
|
|
感谢banq大哥的答复，但小弟还有一些疑惑：
我们在设计软件架构的时候，自然要考虑性能、兼容性、扩展性等。我也看了一下jdon架构下的演示，速度是不错，但这个根本不能说明问题啊。我们做单表维护的时候，速度方面也不比这差。甚至我们在做一些复杂业务的处理，比如发货处理（从收货单导入发货单，处理客户信息，更改库存台账，生成应收应付单等等），后台的业务处理也不会超过7~8秒，所以业务层和数据访问层还是经受住了考验的。但前台的页面展现采用的是第三方工具，在前文我也描述过了，我想问问在页面查询、输入控制以及对按钮事件的捕获处理等有没有更好的工具，或者处理方式，既能像extra那样保证我们的开发速度，又能提供稳固的性能。这样的话我们只需要修改一下页面就能使我们的系统性能提升一个档次。
顺便说一说Extra提供的方便之处：（1、jdbc连接 2、在1的基础上实现数据的查询和显示 3、按钮、翻页以及各种事件捕获处理以及输入控制等等）
|
|
|
|
|
|
Re: 关于系统性能的一个问题
|
发表: 2005年09月05日 11:31
|
回复
|
|
Jdon框架是完全体现在表现层，对你问的"页面查询"支持不但从页面制作到运行都有非常Strong的支持。你可能误解了Jdon框架位置，Jdon框架是插入表现层和业务层如你的EJB之间一个代理加速器，通过Jdon这个加速器，可以加速你的页面展现性能。
至于“输入控制以及对按钮事件的捕获处理”推荐使用JSF框架。
我说过，性能不只是某个层的问题，“业务层和数据访问层还是经受住了考验的”我对这句话表示怀疑，你通过严格的Jmeter负载性能测试吗？单凭自己内部人员操作感受是不一样的，我曾经经历一个单用户系统，如果不是通过性能测试，都不知道它被设计成一个单用户系统，是非常可怕的。
另外，对于表现层的选择，必须有主次之分：最重要的是：
一个好的表现层技术是必须和业务层分离的，特别是更后面的持久层。这是JSF/Tapestry等表现层框架竭力提倡的，否则如果单追求开发速度，不如使用delphi/vb传统两层，何必选择因多层而生的Java呢？
另外，对于你的“开发既快 性能又好”的要求是我个人认为是不切实际的，因为我之前说过，性能属于架构设计，不是用某个框架就可以解决，它是一种模式，涉及各个层的设计和编码。
因为我们一般做项目时很少有设计这一步骤，所以也就没有性能设计，这导致的后果是：没有非性能方面的设计无非是代码臭一些(只有程序员自己能闻到)；不会打击系统正常运行；但是没有性能设计，就会影响很大，很多Java系统失败都是这个原因，以前很多人说EJB不好，导致项目失败，主要也是这方面原因。
所以，我建议你这样的系统必须从性能角度重整一下，具体重整方法很多，主要是加入缓存机制和批量查询，这些你如果想自己做，可以参考jdon框架源码或其他一些框架源码。当然，直接使用是最快的，主要目的是测试一下这种性能设计方案是否有效。
|
|
|
|
|
|
Re: 关于系统性能的一个问题
|
发表: 2005年09月05日 16:28
|
回复
|
|
|
你自己分析的很对啊，就是在客户机上javascrip的执行效率太差了，你最好使用servlet，在服务器上把需要展现的页面解析生成，这些可以写成公用的类库。
|
|
|
|
|
|
Re: 关于系统性能的一个问题
|
发表: 2005年09月06日 13:59
|
回复
|
|
楼主说的extra我了解一点,他们公司的人员曾经到过我们这里推广,但是由于一些原因,后来我们没有采用.
这个工具对页面的处理非常令人心动,可以省掉很多开发的工作,特别是表格和下拉控件这部分,处理的效果跟c/s的页面差不多.
企业业务系统对录入的速度要求很高,很多内容都需要通过下拉控件进行选择,比如录入销售订单的时候,需要的客户信息,部门信息,人员信息,商品信息等这些,数据库中数据量比较大,尤其是商品信息.用extra可以在配置文件中写sql查询语句,然后和控件绑定,显示比较方便,但是如果数据量大而且需要显示的基础数据种类很多,那效率就会很低.这也是我们当时没采用的一个原因. 不过听说可以不通过直接用查询语句进行绑定,可以传入数据集,这样的话,楼主就可以把一些数据集放在缓存里面,速度就会快很多,不过这样内存可能需要稍微大点,具体的楼主可以咨询一下extra的提供商,他们应该能给出一个解决方案.
刚刚完成一个企业信息化的项目,采用b/s架构,以前对页面处理关注很少,这次在这上面花了很多精力,打算在以后的项目中也借助extra类似的工具来处理页面这部分以减少工作量,楼主如果圆满地解决了这个问题,希望你能分享一下你们的做法
|
|
|
|
|
|
Re: 关于系统性能的一个问题
|
发表: 2005年09月09日 07:34
|
回复
|
|
呵呵, 偶虽然对EXTRA不熟, AJAX还是写过一点点的.
提几个建议:
1. 弄清楚 BOTTLENECK 是在 JAVASCRIPT, 还是在网络传输, 还是在服务器.
2. 如果是网络, 考虑异步传输数据. 先穿一部分, 然后慢慢传其他的, 想GMAIL那样.
3. 如果是JAVASCRIPT, 改善JAVASCRIPT程序. JAVASCRIPT里有很多东西是效率很低的. 比如字符串操作, 在IE的JAVASCRIPT 引擎里是O(N*2)操作. 也就是说, 简单的String + String多了就会导致性能问题. 很多情况下, 如果字符串合并操作很多(通常AJAX会有很多合并操作), 要考虑写自己的StringBuffer类(当然类在Javascript里面是函数, 或者模板, 取决于设计).
4. 关于javascript 和 Ajax, 用Mozilla Venkaman调试一下Gmail或者Google Map, 会有心得的.
|
|
|
|
|
|
Re: 关于系统性能的一个问题
|
发表: 2005年09月12日 14:15
|
回复
|
|
你好,我们公司的项目跟你的架构非常类似，底层用Hibernate,表示层用extra,只不过中间没有用EJB,我们用extra也有一段时间了,当初选用extra也是因为它可以提供像动态表格这样的的一些组件功能.在性能方面我也有跟你类似的遭遇,有些地方我认为是可以优化的,下面是我们用extra的时候的一些做法，写出来跟您交流(extra3.7.1):
extra有两种获取数据的方式，一种是直接sql的方式，一种是datagetter方式，我们感觉直接sql的方式性能比较好，但是不适合用在复杂变化查询条件方式（我们公司的大部分页面查询都非常复杂），因此，我们的大部分查询逻辑都是这样做的：datagetter先调用Service类，，然后Service再调用DAO，我们的service可能有点像你们用的EJB层,包含了事务处理的逻辑和业务逻辑。
extra的表示层功能跨越了client端和server端，因此要优化性能需要在以下几个方面努力：
1、client端显示性能的优化
2、client端到server端数据传输性能的优化
3、server端获取数据生成返回结果性能的优化
先说第一条，client端显示性能的优化，extra本身是一种rich web client架构，页面有好多script生成的对象，script是解释执行的,所以肯定会比静态页面慢不少,所以优化的重点就是script.
1、优化dataset,没有用的字段最好删掉.
2、减少dataset滚动时候或记录级别的事件,如果一定要用,建议用disablecontrol和enablecontrol
3、下拉框之类的dataset建议用sql方式,并允许缓存(但是如果下拉筐是动态变化的,则不能缓存)
再说Server端的优化:
1、使用datagetter的分页查询功能,结合Hibernate的分页查询功能,这点可以大大提高性能(我们的做法是写了一个PagingDataGetter类继承了extra的DataGetter)
2、对于性能要求很高的,避免使用DataObjectUtil,手工完成Bean到dataset的转换
3、给datagetter的bean尽量使用扁平结构的valueObject,不要使用多层结构的Bean(就是Bean中的某些属性还是一个Bean).
4、在后台使用一些缓存机制(这点跟extra无关,但在并发访问量上升的时候是关键因素)
最后是网络传输的优化:
网络传输方面我们没做过什么优化.
|
|
|
|
|
|
Re: 关于系统性能的一个问题
|
发表: 2005年09月13日 11:57
|
回复
|
|
非常感谢bravemouse的优化方案，实际也是一个关于前台是javaScript的优化方案。
后台Server端优化基本是架构优化，对第一点疑惑：
hibernate的分页查询功能是如何实现？使用Open Session in View吗？
第二点优化主要取决于你的缓存方案，如果缓存方案不支持嵌入式对象，最好做成扁平Bean。
第三点优化只有在压力测试下才能看出变化出来，一般自己手工凭感觉是看不出来的。
|
|
|
|
|
|
Re: 关于系统性能的一个问题
|
发表: 2005年09月14日 14:43
|
回复
|
|
to banq:
谢谢banq，我说的Hibernate分页查询指的就是Hibernate提供的类似如下方式的查询：
Query q = session.createQuery("from Cat as c");
q.setFirstResult(20000);//设置第一行的位置
q.setMaxResults(100);//设置最大行数
List l = q.list();
我看过一些Hibernate生成的sql，hibernate会根据不同的数据库生成不同的分页查询语句，如在oracle中会生成包含rownum的语句，这样一次查出来的只是一小部分数据，比一下查出很多条，然后再获取一部分要快不少,不过可能有的数据库不支持分页查询
|
|
|
|
|
|
Re: 关于系统性能的一个问题
|
发表: 2005年09月23日 10:03
|
回复
|
|
|
会不会不一定是extra的问题，可能数据库瓶颈问题呢？
|
|
|
|
|
|
Re: 关于系统性能的一个问题
|
发表: 2005年09月26日 17:00
|
回复
|
|
|
呵呵 ，看来大家对性能问题都比较感兴趣，我没有什么高见 ，不过看见这个帖子比较好 ，来帮忙顶顶
|
|
|
|
|
|
看来用extra的公司还真不少啊
|
发表: 2005年10月09日 09:56
|
回复
|
|
|
|
|
|
|
|
Re: 关于系统性能的一个问题
|
发表: 2006年08月03日 17:45
|
回复
|
|
|
Extra这是一个什么东东，我在网上查了一下.说是基于Rich ClientWEB开发平台.现在有没有类似的开源软件，我想研究一下
|
|
|
|
|
|
Re: 关于系统性能的一个问题
|
发表: 2006年08月07日 18:30
|
回复
|
|
看了楼上这些大哥对于doroda的评语，我想提出我的一些看法。我这里可以大概介绍一下我们所使用的表现层架构。
和doroda相比，我们采用的是纯正的swing作为表现层，JWS作为智能客户端的发布工具，是一套真正的RIA架构。我们的架构叫做RAB(Rapid Applicaton Builder)。
我们的侧重点时降低整个软件开发过程的复杂度，通过良好的封装以及友好的集成开发环境构建系统。与Doroda相比我们更像是一个基础平台，和EOS属于同一类型产品。
与Doroda类似的地方是，我们同样重视表现层的开发。我们自主开发了一套完全基于Swing的组件，有强大的数据表单窗口，有多样式的下拉组件，有多格式的掩码组件，以及日期控件，树型控件。数据表单窗口可以让用户自定义编辑器以及显示的格式。当然我相信这些组件我们能做的Doroda肯定也能在Web上实现。
由于我们使用客户端本地资源以及Java虚拟机的支持，首先在内存管理和利用率方面就远远高出doroda一筹。其次我们做了更一步优化，在数据表单窗口中我们加入了增、删、改3个缓冲区，下拉框中加入了分页设计。
我们还可以充分利用客户端的缓冲将每次Update时的数据做缓存，在update数据提交时，只提交修改后的数据，大大降低了数据流量，此外我们还在客户端和服务器交互的接口加入了压缩，降低了数据包的大小。
此外，我还要着重提出一点的是，Dodora所要做的是尽最大可能像Rich client靠拢，而我们本身就是Rich Client，所以这方面我们有着无法比拟的优势，无论是Doroda的Ajax，还是他做的那些组件，我们都可以凭借Rich client特有的架构，轻松实现。
C/S和B/S的完美结合相信是今后一个趋势。当然我所指的是企业级应用系统。附件中我给出了一个比较资料，以及一个简单介绍。大家有兴趣可以看一下，关于我们平台的设计思想，也可以在"讨论构件业务平台
看到。xf6V8USr0gp4.doc
|
|
|
|
注册
登陆
上一主题
下一主题
