Since Storage Management integrates with different storages frequently located in different environments, be it on premise or cloud, sometimes it's difficult to identify the 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

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

Interpreting the 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. 

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