发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 大数据 扩展性 并发编程 事件驱动 分布式 SOA
1 2 3 下一页 Go 3

关于系统性能的一个问题

                   
2005-09-04 15:16
赞助商链接

偶们公司的软件采用J2EE开发,底层数据的处理是hibernate,业务处理用EJB,一些可重用的组件写放在BO层介于EJB和Hibernate之间。前台页面的展现采用第三方的一个工具,Extra.现在产品开发已经完成,业务处理虽有一些问题,但问题不大。可性能上却值得怀疑。因为我们的页面展现和后台的处理是独立的。但Extra的速度实在在慢了,一是因为这种Taglib要生成大量javascript代码,好多都是全局变量,造成数据流量太大;另一方面由于它在查询数据时要把所有的数据都载入内存,开销极大。偶们的系统包括系统控制,物流,生产,财务,人事,分销,CRM等等,非常庞大。在运行的时候感觉后台的速度也可以,但前台的速度实在太慢了,一个下拉列表慢的时候甚至要十几秒钟,这样要录入几十个字段的数据非疯了不可。

目前想重整架构,想在前台页面这一部分动动手脚。因为Extra在开发的速度方面快得让人羡慕,有点难以割舍。但性能的要求使我们不得不考虑新的方式。请问大家在页面展现方面有没有一些好的方式。请不吝赐教,小弟初来咋到,在这里谢过了!

2005-09-04 16:45

唉,你这个问题真是一个典型案例啊,这个案例教训说明了下面几个问题:

1. 项目开始之初,架构选择是设计和性能等因素的综合平衡考虑,特别是在选择现有框架时,对其需要从几个方面进行考核:
Scalability Transparency Extendable Performance Availability。

2.注意这些框架选择之后,它们在搭配组合方面是否有一些陷阱,如性能陷阱等。

3. 其实对于实际应用来说,因为有这些现成框架帮助我们实现了设计目标,所以我们的重点需要放在性能上,说白了,是要在内存状态和数据库持久化状态之间做一个平衡,比如,帖子的浏览数,一般都习惯使用数据库一个字段增1,但是这是个性能尖刀,访问量大时会最先冲击系统稳定性,所以,应该使用内存状态变量保存浏览数,定期写入数据库即可。

4.一个项目需要一个性能架构考虑,性能考虑和其他考量是不同的,是另外一条方向,要有专门人员深入设计,这点一般系统最容易忽视。性能一旦出现问题,就象内存泄漏一样,不是某个环节的问题,而是整体架构到详细设计编码等各个环节问题。

以你这个案例,性能问题你认为是查询时将所有数据载入内存所导致,但是这种做法不是某个框架的错,因为它的优化目标不是在这里;这也说明引入一个框架能够全面知道其优缺点,特别是性能勿视点很重要,而目前这是大部分框架的一个通病。

当然,这里免不了我介绍我设计的开源框架Jdon Framework,它有两个快速开发/快速运行的特点:1.CRUD(增删改查) 2.批量查询,这些都可以从相关演示和测试中了解。

你可以使用jmeter作为模拟不同网址(不同session)客户端对你的系统进行测试,包括引入性能提升框架如Jdon框架的前后对比。




2005-09-05 10:47

感谢banq大哥的答复,但小弟还有一些疑惑:

我们在设计软件架构的时候,自然要考虑性能、兼容性、扩展性等。我也看了一下jdon架构下的演示,速度是不错,但这个根本不能说明问题啊。我们做单表维护的时候,速度方面也不比这差。甚至我们在做一些复杂业务的处理,比如发货处理(从收货单导入发货单,处理客户信息,更改库存台账,生成应收应付单等等),后台的业务处理也不会超过7~8秒,所以业务层和数据访问层还是经受住了考验的。但前台的页面展现采用的是第三方工具,在前文我也描述过了,我想问问在页面查询、输入控制以及对按钮事件的捕获处理等有没有更好的工具,或者处理方式,既能像extra那样保证我们的开发速度,又能提供稳固的性能。这样的话我们只需要修改一下页面就能使我们的系统性能提升一个档次。

顺便说一说Extra提供的方便之处:(1、jdbc连接 2、在1的基础上实现数据的查询和显示 3、按钮、翻页以及各种事件捕获处理以及输入控制等等)

2005-09-05 11:31

Jdon框架是完全体现在表现层,对你问的"页面查询"支持不但从页面制作到运行都有非常Strong的支持。你可能误解了Jdon框架位置,Jdon框架是插入表现层和业务层如你的EJB之间一个代理加速器,通过Jdon这个加速器,可以加速你的页面展现性能。

至于“输入控制以及对按钮事件的捕获处理”推荐使用JSF框架。

我说过,性能不只是某个层的问题,“业务层和数据访问层还是经受住了考验的”我对这句话表示怀疑,你通过严格的Jmeter负载性能测试吗?单凭自己内部人员操作感受是不一样的,我曾经经历一个单用户系统,如果不是通过性能测试,都不知道它被设计成一个单用户系统,是非常可怕的。

另外,对于表现层的选择,必须有主次之分:最重要的是:
一个好的表现层技术是必须和业务层分离的,特别是更后面的持久层。这是JSF/Tapestry等表现层框架竭力提倡的,否则如果单追求开发速度,不如使用delphi/vb传统两层,何必选择因多层而生的Java呢?

另外,对于你的“开发既快 性能又好”的要求是我个人认为是不切实际的,因为我之前说过,性能属于架构设计,不是用某个框架就可以解决,它是一种模式,涉及各个层的设计和编码。

因为我们一般做项目时很少有设计这一步骤,所以也就没有性能设计,这导致的后果是:没有非性能方面的设计无非是代码臭一些(只有程序员自己能闻到);不会打击系统正常运行;但是没有性能设计,就会影响很大,很多Java系统失败都是这个原因,以前很多人说EJB不好,导致项目失败,主要也是这方面原因。

所以,我建议你这样的系统必须从性能角度重整一下,具体重整方法很多,主要是加入缓存机制和批量查询,这些你如果想自己做,可以参考jdon框架源码或其他一些框架源码。当然,直接使用是最快的,主要目的是测试一下这种性能设计方案是否有效。



2005-09-05 16:28

你自己分析的很对啊,就是在客户机上javascrip的执行效率太差了,你最好使用servlet,在服务器上把需要展现的页面解析生成,这些可以写成公用的类库。

3Go 1 2 3 下一页

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系管理员 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com