SAP Personas 3.0 performance

[Former Member]

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

[kmagons]

Hi Florian,

We would need more information before suggesting any further steps

- Check /n/personas/admin Health Check report, make sure there are no configuration red traffic lights and the installation is up-to-date

- What are your SAP Kernel and SAP Screen Personas versions?

- Which rendering engine is used - SE, SAP GUI for HTML or SAP GUI for Windows? Did you compare the performance of an alternative rendering engine?

- Is the performance problem only reproducible with a specific flavour? Did you try switching SAP Screen Personas off by adding sap-personas-runmode=0 parameter?

- Did you try suppressing load script execution to make sure the custom scripts are not the cause of poor performance?

- Try to compress Undo history, more changes in the flavour means more processing

Thank you!

Best,

Krists Magons

SAP Screen Personas Dev team

[cris_hansen]

Hi Florian,

Please watch, read and follow the documentation below:

• Performance comparison

• Performance Optimization Guide

• Optimizing Scripts

• Optimizing Scripts and Events

• Rendering fields across tabs without Tab Merging

I hope this helps,
Cris

[Former Member]

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

[tamas_hoznek]

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.

[Former Member]

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

[Former Member]

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

[tamas_hoznek]

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.

[Former Member]

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.

[Former Member]

Here is the rest of the files

[Former Member]

script-onafterrefresh.txt

[tamas_hoznek]

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.

[Former Member]

I have modified the script with all hints from the video. All data declarations ("var = ") at the beginning and all write actions at the end of the script. But the changings did not lead to a better performance.

So I tested something. First I deleted the script from the onAfterRefresh and executed the program without the script. Time was about 2 seconds. This would be OK.

Then I set the script again but in the script were no write actions. I just wrote the coding for the data declaration. I executed the program again. Time was about 3-4 seconds. Would still be OK.

Then I set the complete script (as you can see attached). Performance still as bas as before. Time was about 7 seconds.

So I thought the bas performance might come from a bad network. But obviously the script is the problem. And obviously the write actions in the script is the problem.script-modified.txt

[dr_ajt]

While your links may have been helpful when you posted them they currently link to private videos on YouTube that I can't watch or a page not found error in SAP's site.

We've recently upgraded the SAP kernel and are seeing very poor performance on flavors that were previously acceptable. I'd be very interested in knowing what was in the videos too. Basically you see the default blue screen for a second or two before the page renders in the flavor - the business, understandably, isn't happy with the change...

[cris_hansen]

Hi Adam,

I need to check why the videos are no longer available, as they were from the SAP Screen Personas team.

Maybe things changed (2.5 years post). I will update this thread, with another comment.

Regards,

Cris

[cris_hansen]

Hi dr_ajt,

Performance comparison - I couldn't find the video anymore, but this blog can help (even though old): https://blogs.sap.com/2013/08/15/sap-screen-personas-performance-vs-sap-gui/
Performance Optimization Guide - https://help.sap.com/doc/51d993b3095447b1ab0fb6654019f039/3.0.7/en-US/loio561f367c80604bef9004c0171e...
The videos about "Optimizing Scripts", "Optimizing Scripts and Events" and "Rendering fields across tabs without Tab Merging" disappeared.
I'll reach out my colleagues and see whether they can be shared again.

Regards,
Cris