Hibernate Search 4.3.0.Beta1版本现在可在Maven存储库和Sourceforge中找到。
有什么新功能?
- NRT后端性能提升
- 空间API变得更加友好
- JBoss部署模块改进(错误修复)
- 兼容JBoss EAP 6.1
更多详细信息可以在JIRA过滤器中找到。
NRT用户性能提升
我们获得了全新的性能测试套件,因此我们开始使用它并发现了之前测试中遗漏的一些有趣的优化机会。受影响的NRT后端(近实时)存在一些不必要的锁定竞争,在某些场景中可能导致显著减速。
那么我们讨论的修复是什么类型的?让我们先看看最新最终发布版本的新测试的性能结果。
性能报告:Hibernate Search 4.2.0.Final
SUMMARY Name : FileSystemNearRealTimeTestScenario Memory usage (total-free): before : 37MB after : 40MB TASKS 10000x InsertBookTask | sum 25:24.769 | avg 00:00.152 10000x UpdateBookRatingTask | sum 25:01.950 | avg 00:00.150 10000x UpdateBookTotalSoldTask | sum 22:54.125 | avg 00:00.137 10000x QueryBooksByAuthorTask | sum 20:22.324 | avg 00:00.122 10000x QueryBooksByAverageRatingTask | sum 30:21.692 | avg 00:00.182 10000x QueryBooksByBestRatingTask | sum 39:56.530 | avg 00:00.239 10000x QueryBooksByNewestPublishedTask | sum 27:02.078 | avg 00:00.162 10000x QueryBooksBySummaryTask | sum 27:19.568 | avg 00:00.163 10000x QueryBooksByTitleTask | sum 27:49.037 | avg 00:00.166 10000x QueryBooksByTotalSoldTask | sum 26:01.403 | avg 00:00.156 TEST CONFIGURATION threads : 10 measured cycles : 10000 warmup cycles : 100 initial book count : 1000000 initial author count : 10000
现在让我们看看有多少改进。
性能报告:Hibernate Search 4.3.0.Beta1
SUMMARY Name : FileSystemNearRealTimeTestScenario Memory usage (total-free): before : 38MB after : 40MB TASKS 10000x InsertBookTask | sum 04:53.440 | avg 00:00.029 10000x UpdateBookRatingTask | sum 04:32.154 | avg 00:00.027 10000x UpdateBookTotalSoldTask | sum 04:41.969 | avg 00:00.028 10000x QueryBooksByAuthorTask | sum 01:58.408 | avg 00:00.011 10000x QueryBooksByAverageRatingTask | sum 12:02.741 | avg 00:00.072 10000x QueryBooksByBestRatingTask | sum 12:26.415 | avg 00:00.074 10000x QueryBooksByNewestPublishedTask | sum 12:01.274 | avg 00:00.072 10000x QueryBooksBySummaryTask | sum 07:08.790 | avg 00:00.042 10000x QueryBooksByTitleTask | sum 02:03.112 | avg 00:00.012 10000x QueryBooksByTotalSoldTask | sum 11:54.997 | avg 00:00.071 [same configuration]
以下为传统免责声明:不要期望您的应用程序能够获得完全相同性能提升。其他应用程序很可能受益于这一点,但规模可能不同。这就是为什么我不分享硬件细节,它们并不相关:只需说这些测试是在相同的条件下进行的,因此它们是可比较的。
我们无法测试所有应用程序,但我认为我可以作为一个有根据的猜测来声明,我不期望出现性能恶化的情况。对于使用近实时IndexManager的任何应用程序,改进可能是可衡量的,如果您的竞争(更多线程)更高,存储性能较慢或索引显著更大,这些数字可能甚至更好。
感谢您
我想对这些令人兴奋的数字表示对整个Apache Lucene开发团队的感激之情,因为他们创造了Lucene的近实时改进,我们正在在此基础上构建这个功能,并感谢JBoss QA团队的Tomas Hradec创建了性能测试,这些测试解决了问题,并使我们能够对这
如果有人想贡献测试,即使是性能测试,我们将很高兴与他们合作,并使用它们作为未来改进的基础。
常规链接
像往常一样,问题跟踪器是JIRA,所有代码都在GitHub上:欢迎pull请求和任何形式的反馈。
保持关注,并尽快测试此版本,因为最终版本将很快到来!我们计划下周发布候选版本(CR)。