2020-09-12 18:00发布
加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)
在循环内多次调用modelservice.save是否会对性能产生影响
我的理解是,除非您将事务的 enableDelayedStore 设置为true,否则每次调用save(并且模型已修改)都会进行数据库更新。 因此,根据要更新的数量,您可能希望保存在循环外或将事务设置为直到最后才存储在数据库中。 如果循环很大,那么内存将有其他问题,因此,您可以考虑批量保存和提交。
enableDelayedStore
一些非常基本的Groovy可以检验该理论(请记住,我只对5次运行求平均值)
保存循环
开始= System.currentTimeMillis() (1..500)。每个{ 例如= modelService.create('Product') ex.code =" test $ {it}" ex.catalogVersion = catalogVersionService.getCatalogVersion('默认','分段') 尝试{ p = flexibleSearchService.getModelByExample ex }抓住(e){ p =前 } p.name + ='!' modelService.save(p) } println"获取$ {System.currentTimeMillis()-开始}毫秒"
次
609 619 575 650 557 === 平均= 602毫秒
节省循环
开始= System.currentTimeMillis() 项目= [] (1..500)。每个{ 例如= modelService.create('Product') ex.code =" test $ {it}" ex.catalogVersion = catalogVersionService.getCatalogVersion('默认','分段') 尝试{ p = flexibleSearchService.getModelByExample ex } catch(de.hybris.platform.servicelayer.exceptions.ModelNotFoundException e){ p =前 } p.name + ='!' 项目<< p } modelService.saveAll(items) println"获取$ {System.currentTimeMillis()-开始}毫秒"
480 502 482 465 464 === 平均= 479毫秒
延迟商店
开始= System.currentTimeMillis() de.hybris.platform.tx.Transaction.current()。enableDelayedStore(true) (1..500)。每个{ 例如= modelService.create('Product') ex.code =" test $ {it}" ex.catalogVersion = catalogVersionService.getCatalogVersion('默认','分段') 尝试{ p = flexibleSearchService.getModelByExample ex }抓住(e){ p =前 } p.name + ='!' modelService.save(p) } println"获取$ {System.currentTimeMillis()-开始}毫秒"
519 530 531 522 494 === 平均= 519毫秒
是的,我对其中的区别感到惊讶。 下一步是在运行时启用jdbc日志,并查看正在发出的查询。 从hac运行时,我也不完全确定此测试的有效性,因为大概它只是在脚本完成后才提交事务,而实际上是在我们的计时完成之后。
基本上可以,这不是最优化的方法,所以可以产生影响。 现在,根据您对性能的需求,可以忽略此影响。
与性能方面的任何问题一样,我想说的是,您必须尝试一下它是否足以满足您的需求。
您不必担心这种优化,正如您在安德鲁(Andrew)的测试中所看到的,我们所说的是微优化。
如果您需要非常短的响应时间,则可以使用Transaction来限制与DB的连接。
您可以检查hybris参考: https://help.hybris.com/1808/hcd/8c7387f186691014922080080f2e053216a。 html
最多设置5个标签!
我的理解是,除非您将事务的
enableDelayedStore
设置为true,否则每次调用save(并且模型已修改)都会进行数据库更新。 因此,根据要更新的数量,您可能希望保存在循环外或将事务设置为直到最后才存储在数据库中。 如果循环很大,那么内存将有其他问题,因此,您可以考虑批量保存和提交。一些非常基本的Groovy可以检验该理论(请记住,我只对5次运行求平均值)
保存循环
次
节省循环
次
延迟商店
次
是的,我对其中的区别感到惊讶。 下一步是在运行时启用jdbc日志,并查看正在发出的查询。 从hac运行时,我也不完全确定此测试的有效性,因为大概它只是在脚本完成后才提交事务,而实际上是在我们的计时完成之后。
基本上可以,这不是最优化的方法,所以可以产生影响。 现在,根据您对性能的需求,可以忽略此影响。
与性能方面的任何问题一样,我想说的是,您必须尝试一下它是否足以满足您的需求。
您不必担心这种优化,正如您在安德鲁(Andrew)的测试中所看到的,我们所说的是微优化。
如果您需要非常短的响应时间,则可以使用Transaction来限制与DB的连接。
您可以检查hybris参考: https://help.hybris.com/1808/hcd/8c7387f186691014922080080f2e053216a。 html
一周热门 更多>