Personas 2.0 -- Tabs caching more than once

[jay_pandit]

Hi folks,

    We are seeing some slow performance on an ME53N (PR Display) flavor on a Personas 2.0 SP3 system, even though we have Delta Rendering and SlimState turned on. We do have a few Tabs Cached on this flavor (admittedly a bit more than the recommended max of 3 or 4 tabs). By watching the browser Console network log, I am seeing that Tabs Caching is occurring once when the flavor initially loads (as expected). When I click on a button on the flavor that pops up a pop-up, and then exit out of that pop-up back to the main flavor screen, Tabs caching occurs again (sometimes twice). I see network traffic pattern that looks similar to that of the tab caching that occurred on initial load, ... which implies the same tabs are being cached again.

    I would not have expected this re-cache. Due to the number of tabs cached in this flavor, each re-cache is costing about 4 seconds of response time. I am wondering whether this re-caching (upon return from pop-up to main screen) is normal and unavoidable, or is it something that can be avoided by some means or settings, since the browser already has the cache from the initial load of the flavor ?  Any thoughts highly appreciated, thx!

Jay.

[chinthan_yajamaan · Accepted solution]

Hi Jay,

It is as expected. Whenever there is a popup or screen navigation the page is reloaded from server and since tab caching is simulating tab clicks on page load, it sends request to load each tab again.

Thanks

Chinthan

[jay_pandit · Accepted solution]

Hi Chinthan,

Yes, I was afraid so, thanks for the confirmation, appreciate it.

Jay.

[jay_pandit · Accepted solution]

Hi Chinthan (or anyone),

I'm still puzzled about why the caching is happening multiple times during the return from the pop-up back to the main me53n screen. See below log from the browser's network traffic console. In our me53n flavor, we have 7 tabs being cached (agree - too many :-)). The tab caching lines are easily recognizable in the log. I understand the first set of tab caching (marked in green in the image), based on your explanation above. However, there is a 2nd set of tab caching that occurs (marked in red in the image) during the return from the pop-up back to main screen, costing ~5 extra secs in response time. Wondering what's causing this 2nd set of caching, and whether this 2nd set is avoidable.  We see the same thing (2 sets of caching) when we click the display-change toggle button on the main me53n screen to put the PReq into change mode or vice versa.  Any thoughts on this would be highly appreciated ! .... Jay.

[chinthan_yajamaan · Accepted solution]

Hi Jay,

It can be either due to onCreateHandler on main screen or a Screen resize event (if users area size is changed because of hiding toolbar or titlebar or statusbar). I am guessing the middle request (between green and red box) is resize (you can go to details and see if request body has height and width parameters).

Thanks

Chinthan

[jay_pandit · Accepted solution]

Hi Chinthan,

Thanks for the response. You're right, On this flavor, we do have onCreateHandler scripting, and we do hide tool&title&status bars, thus changing userarea. That middle line you mentioned between the green and the red box, does have a Request Body that shows width and height parameters

      <url>/rg/action/302/ses[0]/wnd[0]</url>

      <content>width=151&amp;height=36&amp;ua_width=151&amp;ua_height=36</content>

So that explains the double cache in this scenario.  Thx!

I took out the onCreateHandler script temporarily (with tool&titleba&status bars still hidden). The exit from pop-up (i.e. return to the main screen) now cached only once. No resize request and no 2nd caching occured in the log, even though the toolbar/titlebar/statusbar are still hidden. So, I assume both onCreateHandler and Resizing need to be present for the double caching to occur ? Well, on this flavor, we need the onCreateHandler script,  and we need the bars hidden  -- so I guess we'll have to live with double caching in this scenario (exit from pop-up to return to the main screen).

In the other scenario that I mentioned in my prior post:

Clicking the Display<->Change toggle button on main screen : 

( tool&titleba&status bars are hidden. onCreateHandler scripting present ).

This gives the below log:

Here again we see double caching, but strangely, no resize request between the 2 caches.

Tried it with onCreateHandler absent as well (i.e. no onCReateHandler script)

-> exactly same result -> double caching, but no resize request between the 2 caches.

So, in this scenario, not quite sure what's causing the 2nd caching.

Thanks for thoughts (if any) on the second scenario, but already your input has been helped significantly ... much obliged.

Jay.

[chinthan_yajamaan · Accepted solution]

Have you added any "additional action" step in tab caching window?

[jay_pandit · Accepted solution]

There is a "Refresh Screen" script command in "Additional action" in the tab caching window. In one of the Screen Personas practitioners' forum meetings, a customer had mentioned that it helped with response time in their tab merging Flavor.

Anyway, I just deleted this out temporarily, making "Additional actions" completely empty (and "additional actions" checkbox unchecked).  I repeated all the tests, but it does not appear to have made any difference to the Network traffic in any of the scenarios (at least with respect to double caching).

[chinthan_yajamaan · Accepted solution]

Additional action executes for each tab, so it will not help in performance. It is only meant for actions like closing popups that might be interrupting the tab caching. If you can mail me the log file, I can check what is triggering the script action again.

Thanks

chinthan

[jay_pandit · Accepted solution]

Hi Chinthan,

Thanks for the note on 'additional actions' usage ... good to know for future. I have some new info on the 2nd scenario -- that perplexing "Display<->Change" toggle that was exhibiting double caching. We were actually clicking a script button that contained one single script command to Push the toggle.

When we click the toggle (eyeglass-pencil) button directly, the cache occurs only once, as desired ! Why the script button approach causes double caching, I'm not sure. Why we even have a manually clicked script button that has in it just one Push command? --> long story :-). Anyway, the user may as well manually click the pencil button directly (thus result in one cache only). So, I think we're good for now.

Thanks!

Jay.

p.s 1.

Also, we're planning to retrieving some of the info via WebRFC (which is quick),  instead of pulling the info out from the Tabs. This will further reduce the number of Tabs that are needed to be cached, thus helping with performance.

p.s 2.

the log file is a huge 10Mb file (most of the size is Response Body traffic). If you're still interested in it, I could send. But we're ok for now with this 'display<->change' caching scenario.

[sivaganesh_krishnan]

Hi,

When ever you try to  load the screen the caching takes places everytime. so the load increases, which makes the screen slow. Try creating a copy of the flavor and work. Copying flavor will create a fresh copy and will work faster as you expect.

Regards,

Sivaganesh

[jay_pandit]

Hi Sivaganesh,

True, creating a new flavor copy (or simply compressing the flavor and eliminating edit history) does help with flavor load time. Sounds like the re-caching is unavoidable. Thx for you input, appreciate it.

Jay.