HANA：xsodata：第一和第二请求的执行之间巨大的性能差距

如果通过xsodataHANA：xsodata：第一和第二请求的执行之间巨大的性能差距

service namespace "oData" { 
    entity "mySchema"."myView" as "myView"; 
}

暴露VIEW

CREATE VIEW myView AS 
SELECT ... 
FROM ...

和视图创建后表现GET首次/ MyView的极低：

但是：PE后（之后，每次）的性能再次rforming了同样的要求是什么，我希望它是：

问题：

为什么？
如何避免第一次长时间运行的请求？

已经尝试过：

在HANA工作室SQL控制台中的SQL事件探查器输出（无报表编制）的执行提供良好的性能总是
表hotloading（LOAD myTable ALL;）无效果

更新

我们发现“为什么” - 部分：即使请求中没有参数，xs引擎也会将查询作为预准备语句运行。在第一次执行时（在用户的上下文中）查询得到准备，导致M_SQL_PLAN_CACHE（SELECT * FROM M_SQL_PLAN_CACHE WHERE USER_NAME = 'myUser'）中的条目。清除计划缓存（ALTER SYSTEM CLEAR SQL PLAN CACHE）会使oData请求再次变慢，导致性能差异在于重新准备查询的假设。

我们现在坚持第二个问题：如何避免这个问题？我们将标记为重新编译（ALTER SYSTEM RECOMPILE SQL PLAN CACHE ENTRY 123）某些计划缓存条目的方法只是无效的进入，并没有自动更新......

来源

2016-08-19 Benvorth

启用oData分析器：https：//scn.sap.com/thread/3744633 – Benvorth

查询的第一次执行比后续执行慢并不罕见。在第一个执行计划中，高速缓存的生成/优化和创建可能需要一些时间（取决于视图的复杂性和底层表的大小），但是会被缓存并在查询再次执行时可用。 – Goldfishslayer

不幸的是，这使得我们的应用程序变得不稳定，因为语句准备是每个用户（查看'M_SQL_PLAN_CACHE'）。也许有办法“预取”或更新陈述？ 'ALTER SYSTEM RECOMPILE SQL PLAN CACHE ENTRY 1234'只是使条目“无效”（使请求再次变慢），但没有进行“手动”请求就没有更新它... – Benvorth

我不相信你可以REMOVE第一次执行很长一段时间，但你可以尝试将视图更改为在SQL Engine中执行的计算视图。

HANA对于使用其计算视图进行了超级优化，并且计划缓存应该运行得更快，可能会显着缩短第一次执行时间。另外，Calc的计划缓存。应该在用户之间共享视图（因为_SYS_REPO是生成它们的人）。

如果您使用脚本版本，我相信您可以重复使用很多当前的SQL，但您也可以尝试使用图形化方法。

让我们知道你是否有幸运。用大数据进行建模总是令人惊讶。

来源

2016-09-05 19:32:50

HANA：xsodata：第一和第二请求的执行之间巨大的性能差距

回答

相关问题