Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

SAT - Performance Optimization

ishwarya_doss
Participant

Hi All,

I'm currently optimizing some custom logic in exits of VA02.

Executed SAT for particular units in VA02 using /ron and /roff. But it's giving me different results each time I run.

Even some standard tables which were not changed at all is giving high net time in the second time execution of SAT.

Example :

1st run -

2nd run -

What's the ideal way to test the net time post changes? And whats the reason behind this change in net time everytime? PLs suggest.

5 REPLIES 5

Sandra_Rossi
Active Contributor
0 Kudos

Use SAT to know what takes time. Concerning SQL, maybe 5-7 seconds is okay because you read lot of data. Why do you think 5-7 seconds is "bad"?

former_member1702
Participant

Hi Ishwarya,

Please analyze the result of the trace tool. On the left side you will be able to see the split in ( different parts) where program spends it Time. From here you can check what is it that is taking long time.

Also It is possible that more records were created when execution happened second time. And hence more records got fetched and more work needs to be done and this process took longer time.

Hope it helps.

.

ishwarya_doss
Participant
0 Kudos

The total difference between 1st run and 2nd run is huge. I saw someone else using the transaction at the same time. Will that slow down the response?

former_member307439
Discoverer
0 Kudos

Hi Ishwarya,

Ideally, you compare 2 identical executions with almost identical test conditions for testing the performance of a transaction post any changes. So, as you were saying that there were concurrent executions from other users, you can ignore the specific trace and proceed to re-run and recreate the trace with an isolated run similar to your baseline trace (before changes).
Also, note that the trace entries that you have highlighted are DB fetches that are impacted by lower layers in the environment (Network latency from App server to DB and DB response time itself) and any fluctuations in them could alter the performance, hence it is crucial that the SQL statements' key performance indicators in DB are directly reviewed as well for comparison (in HANA you can use views like M_SQL_PLAN_CACHE and M_SQL_PLAN_CACHE_RESET for the same).

Also, do you always see higher time during 2nd execution of the transaction?

Best Regards,

Karthik

gasparerdelyi
Active Participant

First, always there is some natural variation.
Depends on fluctuating load by other users, OS processes, in case of virtualization even partitions, network traffic, database load and so on.

In case you are interested in just measurement of runtime, STAD is most likely a better idea.