在 SAP S/4HANA Public Cloud 里，ABAP 開(kāi)發(fā)人員沒(méi)辦法用 SAPGUI 登錄 ABAP 后臺(tái)了，如果系統(tǒng)出現(xiàn)性能問(wèn)題該怎么辦呢？

答案是在瀏覽器里，使用 Fiori Launchpad 里的各種工具進(jìn)行分析。

SAP 幫助文檔提到，F(xiàn)iori Launchpad 里下列這些應(yīng)用，都能用來(lái)做性能分析：

•  System Workload

•  Sampled Work Process Data

•  HANA Thread Samples

•  System Outbound Communication

https://help./docs/SAP_S4HANA_CLOUD/0cc8af9d2f2e40f38b38b46b49325e2d/877138b5acb84af5b7d2e6411c91d6e4.html

以 System Workload 為例，點(diǎn)擊 Tile 后，能看到 technical monitoring cockpit 界面。

假設(shè)我們要對(duì)一個(gè)基于 ABAP RESTful Application Programming Model(RAP)開(kāi)發(fā)的 Fiori 應(yīng)用的 OData 服務(wù)調(diào)用場(chǎng)景進(jìn)行性能分析。

在 Request Entry Type 里，設(shè)置 OData V2 為過(guò)濾條件，以便專(zhuān)注于 OData 維度的性能指標(biāo)。

在圖表中，單擊看起來(lái)較高的 HANA 處理時(shí)間的對(duì)應(yīng)區(qū)域，例如下午 1:40：

此時(shí)圖表下方的 System Workload: Details 部分會(huì)相應(yīng)刷新，顯示選中的 HANA 處理時(shí)間的主要組成部分，即哪些請(qǐng)求消耗了這些處理時(shí)間。

為了獲取更多詳細(xì)信息，我們選擇上圖列表中第一個(gè)行項(xiàng)目紅色高亮的箭頭符號(hào)。隨后的 Request Processing 屏幕顯示了這個(gè) OData 請(qǐng)求在不同時(shí)間段的執(zhí)行性能數(shù)據(jù)：

該圖表的上部顯示了各項(xiàng)指標(biāo)的累計(jì)總時(shí)長(zhǎng)(Stacked Total Times)，并且根據(jù)在圖表中點(diǎn)擊的內(nèi)容，下部會(huì)呈現(xiàn)出相應(yīng)的詳細(xì)視圖，也就是說(shuō)，它列出了針對(duì)該工作負(fù)載最多20條、按照選擇的指標(biāo)排序的單條 ABAP 統(tǒng)計(jì)記錄。

這樣的設(shè)計(jì)不僅讓開(kāi)發(fā)人員從整體工作負(fù)載的角度把握全局，同時(shí)還能深入了解構(gòu)成工作負(fù)載的每一條具體數(shù)據(jù)，從而大大提升后續(xù)分析的效果。

圖中每條記錄的顏色代碼，是根據(jù)其與服務(wù)器平均響應(yīng)時(shí)間的偏差來(lái)確定的：紅色表示響應(yīng)時(shí)間遠(yuǎn)高于平均水平，橙色顯示略高于標(biāo)準(zhǔn)，而綠色則代表正常的響應(yīng)時(shí)間。

接下來(lái)，我們點(diǎn)擊按鈕 Server Response Time/Request 來(lái)切換視圖：

同前面介紹的累計(jì)總時(shí)長(zhǎng)(Stacked Total Times)視圖一樣，上圖單條記錄的顏色標(biāo)識(shí)，同樣依據(jù)它們與平均服務(wù)器響應(yīng)時(shí)間的偏差來(lái)確定。

圖中每個(gè)請(qǐng)求的平均響應(yīng)時(shí)間大約為一秒；但也有部分請(qǐng)求的響應(yīng)時(shí)間明顯高于這個(gè)平均時(shí)間，因此我們可以深入分析一下這些出現(xiàn)性能問(wèn)題的請(qǐng)求。

在上圖圖表中，選擇首個(gè)標(biāo)紅記錄，即響應(yīng)時(shí)間為 3,474.14 毫秒的那個(gè)請(qǐng)求。

在隨后的 ABAP 統(tǒng)計(jì)記錄頁(yè)面中，餅圖直觀地展示了各部分對(duì)服務(wù)器響應(yīng)時(shí)間的貢獻(xiàn)。其中可以看出，數(shù)據(jù)庫(kù)網(wǎng)絡(luò)時(shí)延(Database Network Time)占據(jù)了主導(dǎo)地位。

另外一個(gè)不尋常之處在于，名為 DEFAULT 的數(shù)據(jù)庫(kù)連接，總共發(fā)起了1,284次數(shù)據(jù)庫(kù)請(qǐng)求。

為進(jìn)一步探查原因，在 ABAP 統(tǒng)計(jì)記錄頁(yè)面的 Database Connection 部分中，選擇首個(gè)連接名稱(chēng)為 DEFAULT 的記錄，以便獲得更多信息。

接著打開(kāi)的 Database Connection Details 頁(yè)面顯示，該連接共發(fā)起了 1,284 次邏輯數(shù)據(jù)庫(kù)請(qǐng)求，檢索了將近 13,000 條數(shù)據(jù)庫(kù)記錄。

這解釋了為何網(wǎng)絡(luò)延時(shí)會(huì)如此之高：?jiǎn)栴}出在這些海量的數(shù)據(jù)庫(kù)請(qǐng)求上。

另一個(gè)比較有用的指標(biāo)，是 ABAP 統(tǒng)計(jì)記錄頁(yè)面中的 SQL Statement 界面，其表格列出了對(duì) HANA 處理時(shí)間貢獻(xiàn)最大的 SQL 語(yǔ)句。

我們可以驗(yàn)證一下對(duì) Booking CDS View 的讀取是否正常。將鼠標(biāo)放到想要查看的 CDS View 記錄上，在彈出的對(duì)話框里選擇 Analyze Statement 即可：

隨后會(huì)打開(kāi) Single SQL Statement Analysis 界面，這里能看到對(duì) CDS View 讀取的 SQL 語(yǔ)句在 HANA 數(shù)據(jù)庫(kù)層面的 Prepared Plan 和 Executed Plan.

HANA 數(shù)據(jù)庫(kù)專(zhuān)家可以根據(jù)這些 Plan 信息來(lái)做進(jìn)一步的性能分析。

其實(shí)以上根據(jù) ABAP SQL 語(yǔ)句展開(kāi)數(shù)據(jù)庫(kù)層面的 Execution Plan，在 ABAP On-Premise 系統(tǒng)的事務(wù)碼 ST05 里也提供了同樣的功能。對(duì)于詳細(xì)的操作步驟，筆者另一套 ABAP CDS View 開(kāi)發(fā)教程也做了詳細(xì)介紹。