Since Storage Management integrates with different storages frequently located in different environments, be it on premise or cloud, sometimes it's difficult to identify bottlenecks.

By identifying and upgrading low-performing components of the data transfer it is possible to greatly increase overall data transfer speed to improve the user experience.

To perform a performance monitoring, we will use SAP standard transaction SAT.

Gathering data

Execute transaction SAT, and create a copy of the default variant
Edit the new variant and check option Measure RFC and Update Calls, Save
Schedule a Glue job that runs for at least 10 minutes, to give us enough time to gather job statistics
After the job is running, start the SAT runtime analysis in parallel session
In the next screen choose a background work process in which is executing the Glue job
Let the the monitoring run for few minutes. You should let the job iterate at least 10 packages to get accurate measurement. Check job logs to identify how many packages were transfered.
To stop the monitoring, click the green box
New screen with monitoring results will appear. Now it's necessary to properly interpret gathered data.

Interpreting data

In general, the processing can be distributed to 3 parts:

Fetching data from database - represented by Data Accesses External (13%)
Glue internal processing - represented by Internal Processing Blocks - Methods / Events (80,85%)
Writing data to Hadoop - represented by Internal Processing Blocks - Function Modules (2,43%)

This example processing distribution is close to ideal, as the major portion of the processing is in ABAP. In this scenario only option to improve the performance is to execute the replication in several parallel jobs.

In case Writing data part is much bigger than in the provided example, it's most likely that the bottleneck is network bandwidth. To improve the performance in this case, it's possible to set a compression on transfer in Storage Management.

If the performance is still not sufficient, upgrade of the network link between source and target environments should be considered.

In the detailed output, several major parts of Datavard code take the most of processing time.

/dvd/sm_cl_hive_ms_csv - Conversion of internal table into CSV format. Usually is the biggest part of execution.
cl_abap_gzip - Compression of CSV file. Can be turned off, but will increase time spent on network transfer.
DB: Fetch - Selecting data from SAP database
/dvd/sm_cl_hive_ms_utils - Escapes special characters in data
/dvd/gl_ext_rul_cl_exe - Execution of custom logic (currency conversions, lookups,...)
HTTP_READ_SC - Waiting for response after sending data to Hadoop. Can be interpreted as "writing time"

Browser not supported