Message Monitor Performance - PO 7.31

[robert_warde4]

We find that viewing stats/messages from previous days and especially weeks takes a considerable amount of the time.Searching via Message Status Overview or Database is very very slow. In some cases the request > 10 minutes and it times out.

I am trying to determine if there is any housekeeping that needs to be performance on the database to improve performance. I have searched SCN/SAP Support but cannot find anything meaningful. Does anyone have any suggestions.

We are running SAP NW PO 7.31 (single stack).

Regards

Rob

[martin_babayan · Accepted solution]

Hi Robert,

what's the size for BC_MSG and BC_MSG_AUDIT tables? How many entries?

BR,

Martin

[robert_warde4 · Accepted solution]

Hi Martin, we are using a single stack system hence these tables do not exist.

[martin_babayan · Accepted solution]

Actually, if you use single Java stack then messages and their Audit logs are stored in these two tables.

BR,

Martin

[robert_warde4 · Accepted solution]

Hi Martin

BC_MSG has 133964 entries and BC_MSG_AUDIT 20583 .

[vadimklimov · Accepted solution]

Hello Robert,

Can you please collect a runtime trace of Message Monitor Overview execution? Particularly, it is of interest to capture distribution of execution time between application server and database and figure out performance killer based on those observations. There are several ways to obtain this trace - here are some of them:

• If you have the PO system connected to Application Performance Management infrastructure, you may look for transaction tracing capabilities in there. For example, if you have Wily Introscope in place, you can use Wily Transaction Trace. This tool will provide you with nice visualization of called functionalities and distribution of execution time and helps to fastly identify most long running calls within executed transaction;
• If XPI Inspector is installed on the PO system, you can collect the trace for inspection example 'RWB' (even though it is named RWB, it works well for PIMON, too). This tool will not visualize execution time components, but will give you a listing of called functionalities and you can calculate long running calls based on its output;
• If none of options above is feasible, you can collect the trace by performing Java profiling for Message Monitor application using performance hotspot analysis. SAP delivers the Java Profiler as a part of JVM Supportability Tools plugin for Eclipse/NWDS (can be downloaded from SAP Marketplace). Literally any other Java profiler will also be suitable here if you use non-SAP profiling tools. This is the most precise approach among mentioned three, but it brings the most overhead to the server node which you profile and its preciseness may be superfluous for current analysis, so I would recommend to consider it only if you cannot collect the trace using other two options listed above;
• If options above are not possible, you can at least collect database trace and check if there were any long running SQL statements that were triggered from Message Monitor. For this, you can use built-in Open SQL Monitors toolset available in NWA, switch on/off and analyze SQL trace there. Please pay special attention to queries against the database table XI_AF_PROF_CACHE - entries from this table are selected and then grouped by Message Monitor Overview in order to present message overview statistics, so poor performance of SELECT queries against the mentioned table may cause overall performance degradation of Message Monitor Overview. If you find expensive SQL statements in this trace, you can progress with database server side analysis, otherwise you anyway will need some tools like those mentioned above in order to analyze application server side.

In order to eliminate potential issues with frontend and network, I would also suggest to collect a trace from the browser - for example, in Internet Explorer and Google Chrome, this can be done using Developer Tools (accessible when pressing F12). There you can record overall execution time spent for request execution and see its distribution per frontend time (processing in the browser), network time and server time (which is load balancer (if you have one), PO application server and database).

Regards,

Vadim

[robert_warde4 · Accepted solution]

Hi,

I've been on leave. Hence the delay in replying. Thanks for your feedback

SAP have released a fix for this. Details below.

2183880 - Message Moni: improve performance during message search. Apply the latest patch of MESSAGING component 7.31 SP14 then check the performance would be improved?

[Former Member]

Hello Robert! Are you interested int stats data? If that is the case, you should use the "Performance Monitor" tool (not "Message Monitor")!

[robert_warde4]

Hi Julio

I am interested in the message data and not stats. Its very very slow which is a concern to me. My only thought is if this is a database issue

Regards

Rob