现有系统在性能调试上的总结

我现在的工作是企业级系统开发,现在参与的系统难点是单事务处理的数据量大(几十万,上百万,这并非数据库表中的数据量,是一次用户的请求就会有这样的数据量存取数据库,做业务处理),同时处理的业务也异常复杂.同时,在现有公司整体架构的范围内(很难类似互联网开发规模的集群处理,多几台服务器似乎也不容易),所做的的一些性能调试的总结:

1.Data partition.这点效果是最明显的,我们现有的数据源有oracle,solr,都有这方面的尝试,切割数据后查询或更新数据的效率提升明显.

2.Server seperate.因为有很多计算逻辑放在应用服务器,所以服务器压力也很大,现有的是按功能进行分离,不同的服务器组负责不同的业务逻辑处理,后面通过EMS来异步通信.

3.Json+ajax替代JSF.因为前端页面的动态效果越来越丰富,要展现的信息也逐渐丰富,前端页面的响应变得迟钝了很多,所以现在逐步用ajax代替JSF,局部刷新页面.当然,还前端还采用的压缩js等的手段来减少响应的时间.

4.solr的采用,全文检索是对我们业务处理非常有帮助的,很多一对多的信息在关系型数据库中,要通过子表去实现,导致冗余的数据增加,查询也慢,而这正是全文检索擅长的,所以从结果来看,也是效果明显.当然,核心数据现在仍然以oracle保存为主.

5.excel的大数据量处理.之前不管是用POI,还是jExcel,几百上千条数据处理还可以,如果上传下载的excel里的数据量到达好几千,上万的话,内存很容易就爆了.原因很简单,通常的处理方式是user model的方式,excel一次读进内存,形成一个POI定义的结构,狂耗内存,研究后可以借助event model及excel 2007的新的基础结构可以一部分一部分的读或者写,不用一次性全部load进内存.具体的可见:http://googi.iteye.com/admin/blogs/1534274

6.前端EMS接受请求,然后异步处理.因为部分功能的业务处理相当复杂,涉及的数据量大,服务器在处理时所占用的内存要好几百M,为避免并发请求导致服务器爆内存,在前端的用户请求我们会首先将其放进queue里,然后服务器再一条一条的取处理依次处理.