鱼雷遇到解放者 – 红工场LiberatorJDO的Torpedo O/R Mapping性能基准测试

Torpedo（鱼雷）Torepdo是Testbed of Object Relational Products for Enterprise Distributed Objects的简称， 是一个java业界发起，由知名的java质询公司The Middelware Company 研究开发，用于测试对象-关系映射中间件(O/R Mapping Software，也成为数据访问中间件)的

性能和优化程度的一个基准测试包。Torpedo包含一个规范，一个用java实现的参考实现( Reference Implementation)。同样的规范可以用C或C#实现以测试该中语言中的O/R Mapping软件。

Torpedo通过精心设计的一系列模拟真实环境中的读写操作来考察O/R Mapping中间件的复杂度，灵活度的和揭示中间件访问数据库的优化策略，通过这些操作的可比结果来衡量O/R Mapping中间件的整体性能和结构设计的优劣。

近年面向对象的开发已经普及，导致新兴的O/R Mapping开发工具也日益增多，包括Enterprise Java Bean中的CMP，JDO，Hibernate, Oralce的TopLink, Coocobase等众多的O/R Mapping中间件和标准的问世，人们越来越需要一个业界测试指标来评估各种的数据访问中间产品，Torpedo正是在业界的这种需求下诞生。

Liberator JDO是由北京红工场软件技术有限公司历近一年时间开发的中国第一个基于POJO模型的O/R Mapping中间件，目前实现了JCP的JDO2（Java Data Object 2）标准的，并会在2006年第一个季度实现EJB3接口和准备实现下一代的业界标准数据持久层API。 Liberator JDO是一个坚实的数据访问中间件，可以作为数据持久层来大量节省项目的开发时间（30%-50%），提高开发效率，提升应用的质量和稳定性。

为了检验Liberator JDO的性能和设计，我们也把Torpedo作为Liberator JDO的测试基准包。通过Torpedo的测试一来保证产品性能和质量，二来也和国外的产品对比，找出弱点，超越对手。

首先看看测试结果:

A-     listAuction; B-listAuctionTwiceWithTransaction; C-listAuctionTwiceWithoutTransaction; D-findAllAuctions; E-findHighBids; F-listPartialAuction; G-placeBid; H-place2Bids

其他国外同类产品包括weblogic, Toplink, Hibernate, Kodo, JDOGenie等的测试结果:

测试结果可以看到看到厂商都很在意测试指标，对自己的产品和torpedo代码进行优化以期在测试中获得优秀的成绩。红工场的Liberator PE在不优化Torpedo的代码的情况下获得很好的成绩，超过了大部分未经优化的其他同类产品的性能指标，和优化后的其他国外厂商的产品在一个数量级上（所有优化后的产品都是在今年夏天后才测试的）。因此Liberator PE不仅仅在性能和设计不逊色于国外的同类产品，在时间上也紧逼业界最领先的国外同行。

现在我们来看看Torepdo到底是测试些什么，和如何侧测试O/R Mapping中间件的。

Torpedo主要测试在O/R Mapping中间件中以下的数据库访问策略。

只读对象(Read only objects)   很多应用大部分的操作都是只读的。聪明的O-R mapping软件应该能够利用这种行为来优化对哪些只读对象的访问。例如，这些数据很容易被缓存并且能够在缓存中存在比较长的时间。

事务内缓存(Caching within a transaction)   O/R Mapping中间件应该可以在单个事务的边界内缓存操作的对象，对这些对象的操作应该不需要操作数据库，所有的针对数据库插入更新操作都应该是在事物提交的时候才执行。

跨多个事务的缓存(Caching across transactions)   虽然在事务的边界内缓存数据可以提供一些好处，跨事务的缓存却能够提供更大的好处。数据不会在并发事务的过程中被重新加载。数据库只会以写操作方式被访问，当数据被修改的时候，对O-R mapping软件来说这是一个具有挑战性的优化操作，尤其是支持在集群环境下或者通过其他非O-R mapping的程序访问数据。

加载对象的部分数据(Partial load of object data)    O-R mapping实例化一个对象的时候，有时只加载这个对象的部分数据比加载所有的更好一些。聪明的O-R mapping软件只加载那些需要的对象数据而不是所有的，这样能够保存在内存资源中提供给应用程序使用。

批量加载多个对象(Bulk loads of multiple objects)    当查询的结果是对象的集合时，通过一次数据库操作加载所有的结果对象比一个一个的加载更好。更进一步的做法是只加载这批结果对象中的一部分

懒惰加载多个对象(Lazy loads of multiple objects)   有时不加载所有的查询结果对象要好一些，更合适的做法是只加载满足基本需要的结果对象。

批量加载被关联对象(Bulk loads of related objects)    当一个面向对象应用程序的一个对象关联另一个对象时，有时通过一次数据库操作就能够加载所有的被关联对象是很有价值的。更进一步的做法是只加载这批被关联对象中的一部分。

懒惰加载被关联对象 (Lazy loads of related objects)有时不加载所有的被关联对象要好一些，更合适的做法是只加载满足基本需要的被关联对象。

批量更新操作(Batch update operations)    相对于在事务过程中频繁执行更新/插入数据库的操作，O-R mapping软件选择了更好的方式，在一次数据库操作中批量的执行更新/插入操作。

在Torepdo的参考实现中，通过一个典型的机遇J2EE架构的拍卖应用来检验上述数据库访问优化策略在O/R Mappping中间件中的实现。Torepdo的对象模型如下图:

对象模型由Auction、Bid、User和Item组成。在这些对象之间有四种不同的关系。Auction和Item之间是一对一的关系，Auction和Bid之间是一对多的关系，一个User和Auction之间是一对多的售货关系。一个User和Bid之间是一对多的买主关系。

基准测试包含9个测试用例，覆盖了所有上述的优化策略：

ListAuction

listAuction操作揭示了O-R mapping软件多么善于通过关联对象找到数据，特别是能够揭示O-R mapping软件是否能够批量加载被关联对象(Eager Fetching)，所有这些信息可以通过一个单独的SQL join statement获得。

ListAuctionTwiceWithTransaction

listAuctionTwiceWithTransaction操作揭示了O-R mapping软件是否能在事务的边界内缓存数据

ListAuctionTwiceWithoutTransaction

测试能否跨事务缓存，也测试O-R mapping软件是否支持只读对象的智能管理，第一次访问auction、bid、user和item的信息被放入缓存中，第二次只会去访问缓存，因为这些对象被声明为是只读的。

ListPartialAuction

listPartialAuction 操作测试O-R mapping软件能够加载对象数据的一部分。listPartialAuction也测试了O-R mapping软件能够用懒惰的方式加载被关联对象。被关联的user和bid对象的信息不是必需的。

FindAllAuctions

FindAllAuctions操作测试O-R mapping软件能够执行批量加载多个对象和懒惰加载。当返回大量数据的时候，这个测试O-R mapping软件呈现批量结果的能力。

FindHighBids

FindHighBids操作测试O-R mapping软件执行批量加载多个对象的能力。它也测试O-R mapping软件的查询语言对合计功能的支持。如果缺少支持，必须要在应用程序中找到最高的出价而不是数据库中。

PlaceBid

测试在同步添加出价信息的时候，placeBid操作测试各种列表和查找操作的正确性。并发执行placeBid操作时，所有的操作必须返回正确的响应。

Place2Bids