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：第一和第二請求的執行之間巨大的性能差距

回答

相關問題