介绍

我早在2000年代就喜欢JPA 1.0。 我甚至在稳定版本发布之前就将其与EJB 3.0一起使用。 我非常喜欢它，因此我为JBoss 3.x实现贡献了一些零碎的部分。

那时我们公司规模还很小。 创建新功能和应用程序比性能更重要，因为我们有很多想法，我们需要尽快开发和营销这些想法。 现在，我们不再需要为数据模型和部署描述符编写繁琐且易于出错的xml描述。 我们也不需要使用名为“ XDoclet”的诅咒。

另一方面，我们的公司稳定增长，我们的网站已成为该国现场直播和票务的顶级门户。 现在，我们遇到了性能问题！ 尽管公司发展Swift，但由于行业经济因素，我们并未赚到多少钱。 我们面临的挑战是我们的公司是一家票务公司。 每个电子商务业务都有旺季和淡季。 但是对于票务来说，是淡季和旺季。 当您每小时售出x张平均票时，当一个大型活动开始销售时，需求突然变成一小时1000张xs。 欢迎来到地狱！

我们昼夜不停地进行调整，以增强应用程序，以使用任何可用的功能来保持一天的正常运行。 坦率地说，无论我们多么努力，总会有一个更大的事件使该网站瘫痪。

梦想结束了，我意识到在框架之上开发应用程序有点“小心！” 以及“乐趣”。

我继续学习

我喜欢编程，喜欢Java，喜欢开源。 我在所有可能的平台上开发了几乎所有可能的类型应用程序。 对于其余的我去发现了东西。 感谢开源，我从大师那里学到了很多东西。 与大多数人相反，我阅读了Linus Torvalds，Gavin King，Ed Merks等伟大的程序员编写的文章和代码。

通过积累的经验，我退出了自己喜欢的票务公司，成为了软件顾问。 这在我眼前开启了一个新时代，那里有很多行业以及许多不同的平台和行业。

在每个项目中，我都成为该应用程序的性能警察。

我现在是表演狂！

我服用了红色药丸！

有一天我对自己说，JPA可以更快吗？ 如果是，那么速度有多快。 我花了大约两个星期的时间来创建一个持久化并加载实体的实体管理器。 然后我运行它，并将结果与​​Hibernate的结果进行比较。 结果并没有真正的希望，我在持久化和查找实体方面仅比Hibernate快50％。 我又花了一个星期来调整循环，缓存元模型块，将对类的访问从接口更改为抽象类，将列表修改为数组等。 突然我有了一个比Hibernate快50倍以上的原型！

Batoo JPA的开发

只关注以性能为中心的编码，性能急剧提高，这让我感到惊讶。 那时，我正在使用Visual VM来衡量在JPA层中花费的时间。 我开始编写了一个自我分析工具，该工具可以测量在JPA层上花费的CPU资源，并开始实施JPA 2.0规范的各个方面。 每次迭代之后，我都会重新运行基准测试，当性能大幅下降时，我会重新进行更改并逐行检查新代码–我创建的性能分析工具报告了JPA Stack每行的性能影响。

整个规范花费了大约6个月的时间，最重要的是，我引入了一个Maven插件来在构建时创建字节码检测，并引入了一个互补的Eclipse插件以允许在Eclipse IDE中使用检测。

Batoo JPA经过6个月的运输，于2012年8月出生。它的测量速度比Hibernate快15倍以上。

基准测试

如前所述，引入了一个基准来测量Batoo JPA的每个微开发迭代。 创建此基准并不是为了提出Batoo JPA很快的领域，以便其他人相信Batoo JPA，而是为了将几乎每个JPA应用程序中存在的最常见的域模型和持久性操作汇总在一起而创建的-我知道快速的Batoo JPA是。

性能指标

该方案是：

• 一个人物对象
  • 带电话号码– PhoneNumber对象

引入了常见的生命周期任务：

• 坚持10万个人对象，每个会话中有两个电话号码和两个地址（每批次10个）
• 找到并加载250K个人对象，每个会话10个
• 每次会话删除5K人对象，每对象5个
• 用100个批次更新100K个人对象
• 使用面向对象的标准查询API查询人员对象25K次。
• 使用JPQL – Java持久性查询语言，类似于SQL的查询脚本语言，可查询人员对象25K次。

为简单起见，该基准测试是在内存嵌入式Derby之上运行的，而探查器将在

• 单元测试层
• JPA层
• 德比层

由于不相关，因此从结果中省略了在单元测试层花费的时间。

结果

下表中给出的时间是运行基准测试场景时在JPA层中花费的毫秒数。 在不同的运行中对Batoo和Hibernate JPA运行相同的测试，以隔离启动，内存，缓存，垃圾回收等效果。

下表显示

• 在Derby层花费的总时间作为数据库操作总计
• 测试的类型为Test
• Derby层作为DB Operation进行每个测试的时间
• 在JPA层作为核心操作的每次测试的时间
• 在JPA层上花费的总时间作为核心操作总计
• 在JPA和Derby层上花费的总时间为Operation Total

以下是Hibernate和Batoo JPA占用的CPU资源的比率。 假定一个应用程序按比率平均生成1个保存，5个定位，2个删除和3个更新以及5 + 5个总共10个查询。 现在，尽管这些数字非常依赖于应用程序的性质，但仍需要某种假设来衡量整体速度比较。

在上述情况下，Batoo JPA的测量速度比领先的JPA实施Hibernate快15倍以上。

您可能已经注意到，Batoo JPA不仅在JPA层上执行得非常快，而且还采用了许多优化措施来减轻数据库的压力。 这就是为什么Batoo JPA在DB Layer上花费的时间是Hibernate的一半的原因。

结果解释

我们非常感谢JPA不是应用程序的单个部分。 但是我们确实相信当前的JPA实现会消耗您的服务器预算中的相当一部分。 尽管典型的应用程序集群在持久层上花费的CPU资源大约为％20到％40，但Batoo JPA仍将其集群减小到其一半大小，从而可以节省大量许可管理和硬件以及腾出空间。即使对于非集群友好的应用程序也可以扩展–根据我的经验，我看到在96核心Solaris系统上运行的应用程序仅仅是因为它们不可扩展。

使用Batoo JPA

结论

我们已经成功创建了一个JPA产品，它使您可以享受JPA Technology的强大功能，但又不要求您牺牲性能！

最重要的是，Batoo JPA是使用Apache编码标准开发的，并且在代码中包含有价值的文档。 该项目代码库是使用LGPL许可证发布的，并且绝对没有封闭的源代码部分，我们预想它将永远这样。

如前所述，它还具有互补的Maven和Eclipse插件，可为构建和开发阶段提供工具。

Batoo JPA与规范的偏差几乎为零，这使得现有JPA应用程序很容易迁移到Batoo JPA，而无需其他学习阶段即可开始使用它。

最后但并非最不重要的一点是，Batoo JPA不仅可以在运行应用程序时节省您的时间，而且可以在部署应用程序时节省您的时间。 Batoo JPA雇用并行部署程序管理器来并行处理部署。 考虑到开发人员在他/她的开发阶段每天部署10次（如果不是100次）的部署，使用中等规模的域模型，总结起来可能会花费相当多的开发人员时间。 尽管我们尚未对部署速度制定具体基准，但我们知道Batoo JPA的部署速度比Hibernate快3到4倍。

感谢您花费大量时间阅读本文，并希望我们为您提供免费的应用程序检查，并演示仅通过替换JPA实施即可获得的收益。

有用的链接：

项目网站– http://batoo.jp/

Batoo JPA的来源和问题管理在Github上托管– https://github.com/organizations/BatooOrg

您可以在StackOverflow.com上讨论Batoo JPA – http://stackoverflow.com/questions/ask?tags=batoo+jpa

翻译自: https://www.javacodegeeks.com/2012/10/batoo-jpa-15x-faster-than-the-leading-jpa-provider.html