Skip to Content
0

SAP Personas 3.0 performance

Apr 05 at 06:50 PM

78

avatar image

Hello,

I am using SAP Personas 3.0 and I have some performance problems. The loading time after any action in the screen is really long.

I have already read the performance guide, but there I did not get any solution, just a few information about the causing.

The program is quite big and has a lot of screen elements (buttons, texts, input fields, pictures) and every element has been changed in the flavor (change of font size, position....). So that might be one reason for the bad performance and long loading time.

I also have created a script which will be executed in the afterRefresh-event. In this script one field will be hidden/shown and another field will be colored differently. That can be another reason.

I already checked some parameters in RZ11 but the values are OK.

In Personas 2.0 it was possible to enable "delta rendering", but this isn't in 3.0. Are there any alternatives?

Does any of you have an idea how I can optimize the performance? Or is there no option because of my big changings of all the screen elements?

Thanks!

Florian

10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

1 Answer

Cristiano Hansen
Apr 06 at 12:22 PM
0
Show 10 Share
10 |10000 characters needed characters left characters exceeded

Hello,

thanks for your help.

But I think none of these would help me with my problem.

We have no tab merging. The script we use is executed in the onAfterRefresh event. There are messages shown in the program and if the message is an error message, then the background color will be changed to red, for success messages the color changes to green. So there is no way to execute this script in other events because it depends on the user action.

I think the main problem is that EVERY screen element has been modified and if I understand it right this modification will be done by Personas every time the screen is loaded. And these are about 60 screen elements.

I also checked the system parameters in RZ11 (performance optimation guide) but these need not to be changed.

So thank you for your help, but I think the problem is that we have to many modified elements.

Florian

0

Hi Florian,

60 changes per screen is a low number and shouldn't cause such performance degradation. If you'd have said 600 or more changes, then maybe, but with so few changes the effect should be negligible. If 60 changes, does that mean 60 elements on the screen, with each element having multiple properties changed? That would mean more than 60 changes. Or just 60 property changes altogether, among a fewer number of fields?

There are a few additional important questions though. What Personas support package are you on? Which transaction is it where you get this performance issue? Did you only change display properties, without causing multiple roundtrips between the backend and frontend by your script(s)? Is your installation fully up-to-date, with all necessary notes implemented? This latest question is important because an onAfterRefresh script is executed at each user interaction, and we used to have some issue with re-processing the change list (serialization, re-application) at each such occurrence. This has, however, been remedied since via a note which is valid from SP05 upwards if I remember correctly.

Generally speaking, if none of these seem to be applicable, then the performance issue is probably more related to ITS tuning than Personas. How does the transaction behave in pure webgui (Original Screen), without a Personas flavor involved? Do you only get significantly worse performance when your flavor is active, or is it already slow when using just the browser?

Regards,

Tamas.

0

Hello Tamas,

If 60 changes, does that mean 60 elements on the screen, with each element having multiple properties changed? That would mean more than 60 changes. Or just 60 property changes altogether, among a fewer number of fields?

Yes, we have rounhd about 60 elements and for almost each element multiple properties are changed (size, position, font size, font color, background color)

What Personas support package are you on?

We use Personas 3.0 but I do not know which support package this is or where I can find this information.

Which transaction is it where you get this performance issue?

It is a new implemented transaction, no SAP standard transaction.

Did you only change display properties, without causing multiple roundtrips between the backend and frontend by your script(s)?

We changed a lot of display properties. We have just one script, which is executed in onAfterRefresh event. In this script there will be changed the background color of one field dynamically and on field will be shown/hidden dynamically. So no big actions.

Is your installation fully up-to-date, with all necessary notes implemented?

I have to check this, if all notes are now implemented. If not, we will do this and if the performance if better after this, I will tell you.

Do you only get significantly worse performance when your flavor is active, or is it already slow when using just the browser?

I checked this and the performance without my flavor is way better.

Thanks for your help!

Florian

0

Hello,

I checked your point with the SAP notes. These notes have been implemented:

2492281, 2492693, 2498331, 2499933, 2500452, 2501686, 2508790, 2511022, 2542143, 2580449, 2583147, 2595514, 2611162, 2491493, 2489350, 2484519, 2483234, 2481967, 2478887, 2477134, 2475942, 2475843, 2474281, 2473858, 2471201, 2467868, 2447935

Regards

Florian

0

Based on this note list, you must be on SP05. It also seems that the system is missing some of the required notes, you can see this when you run the Notes Checker feature in the Health Check tool. It is always recommended to keep the system fully updated - however in this case, I cannot be sure that having an all-green note list will provide better performance.

If all the script does is changing the background color of a single field and also a single field is shown / hidden, this doesn't sound like it would be the cause of a performance issue by itself. However, since this is an onAfterRefresh script, using it will create an additional roundtrip between the backend and frontend at each user interaction - and depending on how your custom transaction is written, this additional, repeated roundtrip may result in performance degradation.

There is also the possibility of some performance issue related to the kernel release / patch level, and even on the DB side. We did have a related case in the past, but without seeing the actual issue, it is difficult to tell what the reason may be. So as you see, there are a lot of various possibilities, and thus the best course of action could be a support incident, with a well-documented use case demonstrating the issue. Then , the support team can log on and analyze the situation to come up with some recommendation on how to fix the problem.

0

Thanks for all this information.

But before I create an incident, I want to show you the program and the health check.

Here you can see the start of the health check health-check.jpg

Here you can see the personas notes checker personas-notes-checker.jpg

Here you can see the program layout without personas

Here you can see the program layout with personas

Here you can see the script

In the program I push the button "F12". There will just be shown another screen. Without personas it will be shown after about 1 second. With personas the duration is about 7 seconds. So it is way higher.

Meanwhile the script has been enhanced. There will set texts as headlines. But this should not influence the performance that much, should it? Because the performance has been bad before this enhancement, too.

So maybe you can just take a look at this, before I will create an incident.

Thanks for your help.

0

Here is the rest of the files

with-personas.jpg (115.3 kB)
0
0

Based on this script, it seems that there is a way to optimize it according to the concept explained in one of the videos linked by Cris earlier.

I'm pretty sure there are several roundtrips generated by this onAfterRefresh script, due to the read / write actions going on. Try to get down the number of those to the minimum possible, and it should help.

0
Show more comments