介紹

我早在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