With the HEUG Alliance 2019
conference starting in a few weeks, it is time to finalize our session schedules. Reviewing the agenda, I see many great education sessions from partners such as Presence of IT
, and Mutara Inc
as well as many, many customer sessions covering important topics including security, user experience, integration, tools, add-on products and so on. This is clearly an Alliance we don't want to miss! On Monday I will be presenting new PeopleTools Tips and Techniques
and then on Wednesday, I am leading the workshop PeopleSoft Fluid: Zero to Hero in an Afternoon
. Session details:
I look forward to seeing you at Alliance 2019!
I have attended your informative and productiove session this year at HEUG. Thanks
We are currently upgrading to Campus Solutions 9.2. As we come to know that fluid pages generate a lot more sessions than classic pages and create performance issue.
Is there any way to calculate & monitor any extra sessions Fluid generates as compare to classic page?
Also, what type of changes we have to apply to our environment(web, app server etc) to address extra load on the system?
Looking forward for your response.
@Mohammad, there should be just one web server session per user (no app server sessions because app server is stateless). What we have found is that Fluid may require more web server memory because of the number of component state blocks reserved at the web server level. For example, every dynamic tile is treated just like clicking the New Window link, reserving a new web server state block (to store the component buffer). Likewise, Fluid homepages make more Ajax requests because each dynamic tile makes a new request. You will see dynamic tiles on homepages and in related content (My Team).
I have not investigated to see if these state blocks are cleaned up over time. I did find it alarming to see the New Window URL state block number increment by a factor equal to the number of dynamic tiles on all homepages. This number increments every time I return home. I've easily seen that number in the 80s, whereas in Classic I rarely saw it over 10. I haven't seen a significant performance impact, however, which makes me wonder about the persistence of these state blocks. I would expect WebLogic to run out of memory a lot faster, but I haven't seen that.
I do not have a tool I use to inspect or view web server memory growth.
Post a Comment