WE had a look into the traces on CPS.

WE opened ST12 and opened the full screen. Then We expanded the (say) first node “User Trace CRM
Performance - Australia” (time 08:03:27).We saw that there are 15 entries; one of these entries has a
duration of 121.998 ms, which is by far the highest (none of the others has more than a second).

So we double-clicked on this line and a certain view of the data opens, that we find helpful for analyses
(“ABAP Trace Per Call top 500”):

From the heading you can see, that database (i.e. SQL statements) consumes 74.6 seconds while ABAP
execution consumes 47.1 seconds, which that the higher attention could be made to the SQL part.

The list itself is sorted according “Gross time”, which means the time from the entry of a (say) function
module (or method) until the exist thereof. Same for SQL statements:

You have to distinguish this from the “Net time”, which excludes the times execution was in a called
function module (or method). This reflects the fact, that if you implement a function module Z and you
have to call another function module S, which itself takes (say) 500 ms, then you cannot be quicker than
these 500 ms when your FM Z is called.

So assume it takes 600 ms time from entering your FM Z until exit, this means you have a “Gross time”
of 600 ms and a “Net time” of 100 ms (600 ms – 500 ms from execution time of FM S).

Another interesting information is the column “No.”, which tells how many times the FM or SQL
statement was called. Sometimes the interesting information is, that a FM or SQL statement is called too
many times (e.g. in a loop within a loop).

But for me the sorting according “Gross time” is less important (for a quick analyses).Weam interested
in the top entries according to “Net time” – here it is:
You probably can see, that almost all entries are DB (i.e. SQL) entries.

If you double click on a line, you are shown the ABAP statement, that caused the SQL (DB) activity that
took the time. E.g. for the first entry (“CL_BUPA_IL_SEARCH_SERVICE=====CP”), you will be shown:

You can see that this statement is called 8 times, which means it took almost 1 second for each of the
calls (914 ms).

So we did the same for some of the Philippine entries:

WE chose the one with time 22:37:20, first entry (time 22:34:51) having duration of 104.090:
You can see that it has a little bit more time for ABAP (54.5 compared to the 74.6 seconds from
Australia), but is has considerably less time for database (49.3 compared to 74.6 seconds), which we find
interesting.

The top entries according “Gross time” look much the same than for Australia:

… but they are not identical; there are the lines: CALL METHOD CL_BSP_PAGE_BASE=>CALL_VIEW, CALL
METHOD CL_BSP_PAGE=>DO_REQUEST. Not sure if this is relevant, but we must admit we cannot
conclude something from that fact.

But let’s look at the view sorted according “Net time”:

We got two top entries with Select ZTA_MOD_PARTNERS, which are completely missing for Australia.
You have the entry, that was the top entry for Australia at 3rd place, with 6 seconds for 9 times
(compared to 7.3 seconds for Australia for 8 times), which to my mind is not too different, to be honest.

WE can tell you a quick win, but this one helps more for Philippines: define some DB index for
ZTA_MOD_PARTNERS:
SELECT * FROM zta_mod_partners
INTO TABLE @DATA(lt_contacts_tmp)
FOR ALL ENTRIES IN @lt_cont_role_id
WHERE partner_rel_guid = @lv_contact_guid
AND role = @lt_cont_role_id-role_id.
 DB index on PARTNER_REL_GUID and ROLE should help!