一个现有EJB系统的性能优化方案

一、问题分析
公司目前维护的一个系统，已经有超过8年的历史。现在遇到严重的性能问题，尤其是查询方面。系统简单介绍如下：
1. 架构：客户端（windows程序）+服务端（J2EE,EJB,Web Service）+数据库（oracle）；
2. 技术特点：
客户端和服务端通过Web Service进行数据传输；
服务端为传统的EJB；
服务端数据采用自行开发的DataSet进行封装，以XML格式返回给客户端；
无DAO对象与领域对象；
无数据缓存机制；
数据库设计严重违背第三范式。

查询经常要从好几个表取数，而且需要将表数据经过复杂的转换（如行列转换）才能得到目标结果，数据量较大，超过5万行。由此产生严重的性能问题，特别是并发访问的情况下。

二、数据库和应用程序服务器的比较
下面列出了本人所了解到的二者分别可以采用的优化方法：
1.数据库
使用存储过程实现查询逻辑，以减少网络交互；
升级数据库服务器硬件。

2.应用程序服务器
使用缓存；
使用分布式、集群应用服务器；
升级应用程序服务器硬件

三、结论
如果系统是按照OO的方式设计，则应用程序服务器上的优化方法自然为首选。但系统没有领域对象，没有DAO对象，全部都采用直接生成SQL语句到数据库取数的方式，数据都用DataSet来封装处理。而DataSet由于实现方式的限制，最多只能包含1万行记录，否则1G的内存就会溢出。而由于使用存储过程实现可以解决减少网络交互、实现分批取数等问题，似乎是最佳的解决方案。

欢迎大家讨论。

评论

4 楼 movingboy 2008-07-03  

你提到查询过程性能问题严重，请问这种查询的结果是否还要做为业务处理的输入？还是只需要把结果给用户查看即可？
如果是后者，考虑一下Oracle的Data Guard的Logical Stand-by或Streams技术。例如使用数据库A进行业务处理，使用数据库B做查询，数据库A的数据使用Logical Stand-by或Streams技术同步/复制到数据库B。如果你们的查询条件是有规则的（比如通常按月查询而不是允许查询任意两天之间的数据），还可以考虑在数据库B把查询结果保存起来，下次查询就只需要读取已保存的结果即可

3 楼 wczwcg 2008-07-02  

Lucas Lee 写道

你的优化方法只是泛泛的方向，没有结合具体实际来考虑是否合适。
首先你得找到瓶颈。数据库执行SQL、转化XML、其它部分各占的时间百分比，然后针对大头部分优化。

我觉得你的使用存储过程的方法实现工作量、优化效果上均不会有很好的表现。
看起来你们没有将结果集分页？这个对性能影响是挺大的。
另外，你们的硬件似乎太老了点，8年没换过硬件吧？可以考虑一下--至少加个几G内存还可以吧。

实际上，我们尝试过2种使用SQL语句的方式。一种是把一部分数据的转换也用SQL实现；一种是只用SQL语句取出原始的数据，数据转换都在服务端进行。因为数据库设计得不合理，所以需要从多个表取数，且数据量较大，而基本上都需要将原始数据全部获取之后进行处理、转换，再考虑以分批的方式返回给客户端。这里面就有较大比重的网络传输时间。
我的考虑是：如果采用服务端的优化方式，因为不能用对象缓存，那么每次的查询都需要重新从数据库取数，性能就无法得到有效的提升。如果用存储过程，就没有了网络传输的开销，而且有些数据转换工作，比如行列转换，似乎通过SQL语句要快一些。但我始终认为，针对数据库的优化始终都是有限的，无法享受应用程序服务器的分布式处理。而且从代码的角度，存储过程的可读性、可扩展性、可维护性，相对Java代码来说都是较差的。

至于硬件，客户那里早就是使用比较高端的服务器了。通常都是2CPU，8G内存之类。

2 楼 feedss 2008-07-02  

升级硬件比动软件更划算

1 楼 LucasLee 2008-07-02  

你的优化方法只是泛泛的方向，没有结合具体实际来考虑是否合适。
首先你得找到瓶颈。数据库执行SQL、转化XML、其它部分各占的时间百分比，然后针对大头部分优化。

我觉得你的使用存储过程的方法实现工作量、优化效果上均不会有很好的表现。
看起来你们没有将结果集分页？这个对性能影响是挺大的。
另外，你们的硬件似乎太老了点，8年没换过硬件吧？可以考虑一下--至少加个几G内存还可以吧。