Poor performance showing BW data in NW portal

[Former Member]

Hi all,

we have a problem with showing data from BW in a NetWeaver Portal here.

There is a table with several different entries displayed on a portal page. When you click one entry some details for this are shown in an area below the table.

Now the problem is that every time you click one entry it lasts around 5 seconds until the details are shown which is much to long.

The data to be shown comes from a BW system.

I know that there are a lot of parameters you can check in BW to optimize performance. But maybe I have a common problem here and one of you can tell me which parameters should be check first.

Thanks for all answers in advance!

Best Regards,

Torben

[Former Member · Accepted solution]

Pal..

Here we can view the problem in two perspectives..

1) If you are displaying the data through a report (BW report) then we need to think about the Quries that were written. There is a possibility that Querries which are in use may take long time.

Suppose if you are trying to retrieve huge amount of data e.t.c

2) this one could be problems from parameters side..As you are loading the data from BW system, it will be using a RFC.

So there are chances that RFC connection could be slow..

Check ST03N dialigue resoponse and RFC times.

Hope this is useful

Regards

PS : Award points if useful

[Former Member]

Hi,

You try to check Memory /buffers in Portal and in BW.You can check backend system by Tcodes ST02, EP from the OS level.

Regards,

Hari.

[Former Member]

5 seconds is not long to get something back from BW if BW has to create it first.

I would run the query while running a trace in the portal for the user (VA - JARM - SAT).

I would then check the trace their and in STAD in the BW system as to which system has the poor performance and then concentrate there.... it would also indicate any netywork issues between the two. If the performance does not reflect what you see then it could be between the portal and the front end but I doubt this if it is only a BW window in trouble. If it is then use a front end trace tool like HTTPLOOK.

SAP does Tout End to End tracing now but I find it is too expensive to set up. Anyway, it is based on other functionality underneath and you can in effect trace most of end to end using DSR statistics in a central CCMS type environment.

If you run the transaction twice in a row, does it run faster the second time?.... that would indicate it is BW based, once the report has been generated there then it will come up faster the second time.

ST02 buffer changes will only make a slight difference unless very very poorly allocated, STAD should indicate this with high processing time although that can also be CPU/Paging based as well. I personally would ensure that all BW DB parameters are correct and the data buffer has a good hit rate. STAD should also indicate this in the fact that a lot of time is spent in the DB as opposed to processing.

Good luck!